Annotation of embedaddon/php/README.RELEASE_PROCESS, revision 1.1
1.1 ! misho 1: =======================
! 2: PHP Release Process
! 3: =======================
! 4:
! 5: General notes and tips
! 6: ----------------------
! 7:
! 8: 1. Do not release on Fridays, Saturdays or Sundays
! 9: because the sysadmins can not upgrade stuff then.
! 10:
! 11: 2. Package the day before a release. So if the release is to be on Thursday,
! 12: package on Wednesday.
! 13:
! 14: 3. Ensure that Windows builds will work before packaging
! 15:
! 16: 4. Follow all steps to the letter. When unclear ask previous RM's (Derick/Ilia)
! 17: before proceeding. Ideally make sure that for the first releases one of the
! 18: previous RM's is around to answer questions. For the steps related to the
! 19: php/QA/bug websites try to have someone from the webmaster team (Bjori) on hand.
! 20:
! 21: 5. Verify the tags to be extra sure everything was tagged properly.
! 22:
! 23: 6. Moving extensions from/to PECL requires write acces to the destination.
! 24: Most developers should have this.
! 25:
! 26: Moving extensions from php-src to PECL
! 27: - Checkout the pecl directory, most likely you want a sparse-root checkout
! 28: svn co --depth=empty https://svn.php.net/repository/pecl
! 29: - Create an directory for the extension incl. branch and tag structure,
! 30: no trunk at this point and commit this to svn
! 31: cd pecl; mkdir foo foo/tags foo/branches; svn add foo; svn commit
! 32: - Move the extension from php-src to the new location
! 33: svn mv https://svn.php.net/repository/php/php-src/trunk/ext/foo \
! 34: https://svn.php.net/repository/pecl/foo/trunk
! 35:
! 36: If the extension is still usable or not dead, in cooperation with the extension
! 37: maintainers if any:
! 38: - create the pecl.php.net/foo package and its content, license, maintainer
! 39: - create the package.xml, commit
! 40: - release the package
! 41:
! 42: For Moving extensions from PECL to php-src the svn mv has to be tone the other
! 43: way round.
! 44:
! 45: Rolling a non stable release (alpha/beta/RC)
! 46: --------------------------------------------
! 47:
! 48: 1. Check windows snapshot builder logs (http://windows.php.net/downloads/snaps/ the last revision)
! 49:
! 50: 2. run the "scripts/dev/credits" script in php-src and commit the changes in the
! 51: credits files in ext/standard.
! 52:
! 53: 3. Bump the version numbers in ``main/php_version.h``, ``configure.in`` and possibly ``NEWS``.
! 54: Do not use abbreviations for alpha and beta.
! 55:
! 56: 4. Commit those changes and note the revision id.
! 57:
! 58: 5. tag the repository with the version. To do the tag in a fast way do a svn copy on the server using full URLs. You should use the revision id from the above commit to prevent mistakes in case there was a commit in between. f.e. "``svn cp https://svn.php.net/repository/php/php-src/branches/PHP_5_3@308399 https://svn.php.net/repository/php/php-src/tags/php_5_3_6RC1``"
! 59: (of course, you need to change that to the version you're rolling an RC for). Mail php-internals to announce the tag so tests/validation/check can be done prior to package it. It is especially important for RCs.
! 60:
! 61: 6. Bump up the version numbers in ``main/php_version.h``, ``configure.in``
! 62: and possibly ``NEWS`` again, to the **next** version. F.e. if the release
! 63: candidate was "4.4.1RC1" then the new one should be "4.4.1RC2-dev" - regardless
! 64: if we get a new RC or not. This is to make sure ``version_compare()`` can
! 65: correctly work.
! 66:
! 67: 7. Commit those changes
! 68:
! 69: 8. Log in onto the snaps box and go into the correct tree (f.e. the PHP_4_4
! 70: branch if you're rolling 4.4.x releases).
! 71:
! 72: 9. You do not have to update the tree, but of course you can with "``svn up``".
! 73:
! 74: 10. run: ``./makedist php 4.4.1RC1``, this will export the tree, create configure
! 75: and build two tarballs (one gz and one bz2).
! 76:
! 77: 11. Copy those two tarballs to www.php.net, in your homedir there should be a
! 78: directory "downloads/". Copy them into there, so that the system can generate
! 79: MD5 sums. If you do not have this directory, talk to Derick.
! 80:
! 81: 12. Now the RC can be found on http://downloads.php.net/yourname,
! 82: f.e. http://downloads.php.net/derick/
! 83:
! 84: 13. Once the release has been tagged, contact the PHP Windows development team
! 85: (internals-win@lists.php.net) so that Windows binaries can be created. Once
! 86: those are made, they should be placed into the same directory as the source snapshots.
! 87:
! 88: Getting the non stable release (alpha/beta/RC) announced
! 89: --------------------------------------------------------
! 90:
! 91: 1. Send an email (see example here: http://news.php.net/php.internals/19486)
! 92: **To** ``internals@lists.php.net`` and ``php-general@lists.php.net`` lists
! 93: pointing out "the location of the release" and "the possible release date of
! 94: either the next RC, or the final release".
! 95:
! 96: 2. Send an email (see example here http://news.php.net/php.pear.qa/5201) **To**
! 97: ``php-qa@lists.php.net`` and ``primary-qa-tests@lists.php.net``.
! 98: This email is to notify the selected projects about a new release so that they
! 99: can make sure their projects keep working. Make sure that you have been setup
! 100: as a moderator for ``primary-qa-tests@lists.php.net`` by having someone (Wez,
! 101: Derick) run the following commands for you:
! 102:
! 103: ``ssh lists.php.net``
! 104:
! 105: ``sudo -u ezmlm ezmlm-sub ~ezmlm/primary-qa-tester/mod moderator-email-address``
! 106:
! 107: 3. Update ``web/qa/trunk/include/release-qa.php`` with the appropriate information.
! 108: See the documentation within release-qa.php for more information, but all releases
! 109: and RCs are configured here. Only $QA_RELEASES needs to be edited.
! 110:
! 111: Example: When rolling an RC, set the 'rc' with appropriate information for the
! 112: given version.
! 113:
! 114: Note: Remember to update the MD5 checksum information.
! 115:
! 116: 4. Update ``web/php/trunk/include/version.inc`` (x=major version number)
! 117:
! 118: a. ``$PHP_x_RC`` = "5.3.0RC1"
! 119:
! 120: b. ``$PHP_x_RC_DATE`` = "06 September 2007"
! 121:
! 122: 5. Commit those changes:
! 123:
! 124: a. ``svn commit web/qa/trunk web/php-bugs/trunk web/php/trunk``
! 125:
! 126: 6. For the first RC, write the doc team (phpdoc@lists.php.net) about updating the
! 127: INSTALL and win32/install.txt files which are generated from the PHP manual sources.
! 128:
! 129: 7. Publish the announce on www.php.net as well (for all releases, alpha, RCs or other)
! 130:
! 131: Rolling a stable release
! 132: ------------------------
! 133:
! 134: 1. Check windows snapshot builder logs (http://snaps.php.net/win32/snapshot-STABLE.log f.e.)
! 135:
! 136: 2. Bump the version numbers in ``main/php_version.h``, ``configure.in`` and possibly ``NEWS``.
! 137:
! 138: 3. **Merge** all related sections in NEWS (f.e. merge the 4.4.1RC1 and 4.4.0 sections)
! 139:
! 140: 4. Commit those changes
! 141:
! 142: 5. run the "scripts/dev/credits" script in php-src and commit the changes in the
! 143: credits files in ext/standard.
! 144:
! 145: 6. tag the repository with the version f.e. "``cvs tag php_4_4_1``"
! 146: (of course, you need to change that to the version you're rolling an RC for).
! 147: When making 5.X release, you need to tag the Zend directory separately!!
! 148:
! 149: 7. Bump up the version numbers in ``main/php_version.h``, ``configure.in`` and
! 150: possibly ``NEWS`` again, to the **next** version. F.e. if the release candidate
! 151: was "4.4.1RC1" then the new one should be "4.4.1RC2-dev" - regardless if we get
! 152: a new RC or not. This is to make sure ``version_compare()`` can correctly work.
! 153:
! 154: 8. Commit those changes
! 155:
! 156: 9. Log in onto the snaps box and go into the correct tree (f.e. the PHP_4_4
! 157: branch if you're rolling 4.4.x releases).
! 158:
! 159: 10. You do not have to update the tree, but of course you can with "``cvs up -dP``".
! 160:
! 161: 11. run: ``./makedist php 4.4.1``, this will export the tree, create configure
! 162: and build two tarballs (one gz and one bz2).
! 163:
! 164: 12. Commit those two tarballs to CVS (phpweb/distributions)
! 165:
! 166: 13. Once the release has been tagged, contact the PHP Windows development team
! 167: (internals-win@lists.php.net) so that Windows binaries can be created. Once
! 168: those are made, they should be committed to SVN too.
! 169:
! 170: 14. Check if the pear files are updated (phar for 5.1+ or run pear/make-pear-bundle.php with 4.4)
! 171:
! 172: 15. When making a final release, also remind the PHP Windows development team
! 173: (internals-win@lists.php.net) to prepare the installer packages for Win32.
! 174:
! 175: Getting the stable release announced
! 176: ------------------------------------
! 177:
! 178: 1. Run the bumpRelease script for phpweb on your local checkout
! 179:
! 180: a. ``php bin/bumpRelease 5`` (or ``php bin/bumpRelease 4`` for PHP4)
! 181:
! 182: 2. Edit ``phpweb/include/version.inc`` and change (X=major release number):
! 183:
! 184: a. ``$PHP_X_VERSION`` to the correct version
! 185:
! 186: b. ``$PHP_X_DATE`` to the release date
! 187:
! 188: c. ``$PHP_X_MD5`` array and update all the md5 sums
! 189:
! 190: d. set ``$PHP_X_RC`` to false!
! 191:
! 192: e. Make sure there are no outdated "notes" or edited "date" keys in the
! 193: ``$RELEASES[X][$PHP_X_VERSION]["source"]`` array
! 194:
! 195: f. if the windows builds aren't ready yet prefix the "windows" key with a dot (".windows")
! 196:
! 197: 3. Update the ChangeLog file for the given major version
! 198: f.e. ``ChangeLog-4.php`` from the NEWS file
! 199:
! 200: a. go over the list and put every element on one line
! 201:
! 202: b. check for &, < and > and escape them if necessary
! 203:
! 204: c. remove all the names at the ends of lines
! 205:
! 206: d. for marking up, you can do the following (with VI):
! 207:
! 208: I. ``s/^- /<li>/``
! 209:
! 210: II. ``s/$/<\/li>/``
! 211:
! 212: III. ``s/Fixed bug #\([0-9]\+\)/<?php bugfix(\1); ?>/``
! 213:
! 214: IV. ``s/Fixed PECL bug #\([0-9]\+\)/<?php peclbugfix(\1); ?>/``
! 215:
! 216: V. ``s/FR #\([0-9]\+\)/FR <?php bugl(\1); ?>/``
! 217:
! 218: 4. ``cp releases/4_4_0.php releases/4_4_1.php``
! 219:
! 220: 5. ``cvs add releases/4_4_1.php``
! 221:
! 222: 6. Update the ``releases/*.php`` file with relevant data. The release
! 223: announcement file should list in detail:
! 224:
! 225: a. security fixes,
! 226:
! 227: b. changes in behavior (whether due to a bug fix or not)
! 228:
! 229: 7. Add a short notice to phpweb stating that there is a new release, and
! 230: highlight the major important things (security fixes) and when it is important
! 231: to upgrade.
! 232:
! 233: a. Call php bin/createNewsEntry in your local phpweb checkout
! 234:
! 235: b. Add the content for the news entry
! 236:
! 237: 8. Commit all the changes.
! 238:
! 239: 9. Wait an hour or two, then send a mail to php-announce@lists.php.net,
! 240: php-general@lists.php.net and internals@lists.php.net with a text similar to
! 241: http://news.php.net/php.internals/17222.
! 242:
! 243: 10. Update ``php-bugs-web/include/functions.php`` to include the new version
! 244: number, and remove the RC from there.
! 245:
! 246: 11. Update ``qaweb/include/release-qa.php``
! 247:
! 248: - Update $QA_RELEASES with the appropriate information, which means bumping
! 249: the version number to an upcoming version.
! 250:
! 251: Example: If PHP 5.3.7 is being released, then PHP 5.3.8 is the next QA version,
! 252: so replace 5.3.7 with 5.3.8 within $QA_RELEASES.
! 253:
! 254: Re-releasing the same version (or -pl)
! 255: --------------------------------------
! 256:
! 257: 1. Commit the new binaries to ``phpweb/distributions/``
! 258:
! 259: 2. Edit ``phpweb/include/version.inc`` and change (X=major release number):
! 260:
! 261: a. If only releasing for one OS, make sure you edit only those variables
! 262:
! 263: b. ``$PHP_X_VERSION`` to the correct version
! 264:
! 265: c. ``$PHP_X_DATE`` to the release date
! 266:
! 267: d. ``$PHP_X_MD5`` array and update all the md5 sums
! 268:
! 269: e. Make sure there are no outdated "notes" or edited "date" keys in the
! 270: ``$RELEASES[X][$PHP_X_VERSION]["source"]`` array
! 271:
! 272: 3. Add a short notice to phpweb stating that there is a new release, and
! 273: highlight the major important things (security fixes) and when it is important
! 274: to upgrade.
! 275:
! 276: a. Call php bin/createNewsEntry in your local phpweb checkout
! 277:
! 278: b. Add the content for the news entry
! 279:
! 280: 4. Commit all the changes (``include/version.inc``, ``archive/archive.xml``,
! 281: ``archive/entries/YYYY-MM-DD-N.xml``)
! 282:
! 283: 5. Wait an hour or two, then send a mail to php-announce@lists.php.net,
! 284: php-general@lists.php.net and internals@lists.php.net with a text similar to
! 285: the news entry.
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to README.RELEASE_PROCESS CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / php