diff options
Diffstat (limited to 'README.RELEASE_PROCESS')
| -rw-r--r-- | README.RELEASE_PROCESS | 156 |
1 files changed, 79 insertions, 77 deletions
diff --git a/README.RELEASE_PROCESS b/README.RELEASE_PROCESS index 6cc9c4e9ab..a0c34f8f7a 100644 --- a/README.RELEASE_PROCESS +++ b/README.RELEASE_PROCESS @@ -8,15 +8,16 @@ General notes and tips 1. Do not release on Fridays, Saturdays or Sundays because the sysadmins can not upgrade stuff then. -2. Package the day before a release. So if the release is to be on Thursday, -package on Wednesday. +2. Package two days before a release. So if the release is to be on Thursday, +package on Tuesday. Think about timezones as well. 3. Ensure that Windows builds will work before packaging -4. Follow all steps to the letter. When unclear ask previous RM's (Derick/Ilia) -before proceeding. Ideally make sure that for the first releases one of the -previous RM's is around to answer questions. For the steps related to the -php/QA/bug websites try to have someone from the webmaster team (Bjori) on hand. +4. Follow all steps to the letter. When unclear ask previous RM's (David/Julien/ +Johannes/Stas/Derick/Ilia) before proceeding. Ideally make sure that for the +first releases one of the previous RM's is around to answer questions. For the +steps related to the php/QA/bug websites try to have someone from the webmaster +team (Bjori) on hand. 5. Verify the tags to be extra sure everything was tagged properly. @@ -50,38 +51,44 @@ Rolling a non stable release (alpha/beta/RC) 2. run the "scripts/dev/credits" script in php-src and commit the changes in the credits files in ext/standard. -3. Bump the version numbers in ``main/php_version.h``, ``configure.in`` and possibly ``NEWS``. -Do not use abbreviations for alpha and beta. +3. Checkout the release branch for this release (e.g., PHP-5.4.2) from the main branch. -4. Commit those changes and note the revision id. +4. Bump the version numbers in ``main/php_version.h``, ``configure.in`` and possibly ``NEWS``. +Do not use abbreviations for alpha and beta. Do not use dashes, you should +``#define PHP_VERSION "5.4.22RC1"`` and not ``#define PHP_VERSION "5.4.22-RC1"`` -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``" -(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. +5. Compile and make test, with and without ZTS, using the right Bison version +(for example, for 5.5, Bison 2.4.1 is used) -6. Bump up the version numbers in ``main/php_version.h``, ``configure.in`` -and possibly ``NEWS`` again, to the **next** version. F.e. if the release -candidate was "4.4.1RC1" then the new one should be "4.4.1RC2-dev" - regardless -if we get a new RC or not. This is to make sure ``version_compare()`` can -correctly work. +6. Check ./sapi/cli/php -v output for version matching. -7. Commit those changes +7. If all is right, commit the changes to the release branch with ``git commit -a``. -8. Log in onto the snaps box and go into the correct tree (f.e. the PHP_4_4 -branch if you're rolling 4.4.x releases). +8. Tag the repository release branch with the version, e.g.: +``git tag -u YOURKEYID php-5.4.2RC2`` -9. You do not have to update the tree, but of course you can with "``svn up``". +9. Bump the version numbers in ``main/php_version.h``, ``configure.in`` and ``NEWS`` +in the *main* branch (PHP-5.4 for example) to prepare for the **next** version. +F.e. if the RC is "5.4.1RC1" then the new one should be "5.4.2-dev" - regardless if we get +a new RC or not. This is to make sure ``version_compare()`` can correctly work. +Commit the changes to the main branch. + +10. Push the changes to the main repo, the tag, the main branch and the release branch : +``git push --tags origin HEAD`` +``git push origin {main branch}`` +``git push origin {release branch}`` -10. run: ``./makedist php 4.4.1RC1``, this will export the tree, create configure -and build two tarballs (one gz and one bz2). +11. run: ``PHPROOT=. ./makedist 5.4.2RC2``, this will export the tree, create configure +and build three tarballs (gz, bz2 and xz). -11. Copy those two tarballs to www.php.net, in your homedir there should be a +12. Copy those tarballs (scp, rsync) to downloads.php.net, in your homedir there should be a directory "downloads/". Copy them into there, so that the system can generate -MD5 sums. If you do not have this directory, talk to Derick. +MD5 sums. If you do not have this directory, talk to Derick or Dan. -12. Now the RC can be found on http://downloads.php.net/yourname, +13. Now the RC can be found on http://downloads.php.net/yourname, f.e. http://downloads.php.net/derick/ -13. Once the release has been tagged, contact the PHP Windows development team +14. Once the release has been tagged, contact the PHP Windows development team (internals-win@lists.php.net) so that Windows binaries can be created. Once those are made, they should be placed into the same directory as the source snapshots. @@ -113,9 +120,9 @@ Derick) run the following commands for you: Note: Remember to update the MD5 checksum information. -4. Update ``php.git/include/version.inc`` (x=major version number) +4. Update ``web/php.git/include/version.inc`` (x=major version number) - a. ``$PHP_x_RC`` = "5.3.0RC1" + a. ``$PHP_x_RC`` = "5.4.0RC1" (should be set to "false" before) b. ``$PHP_x_RC_DATE`` = "06 September 2007" @@ -126,67 +133,61 @@ Derick) run the following commands for you: 6. For the first RC, write the doc team (phpdoc@lists.php.net) about updating the INSTALL and win32/install.txt files which are generated from the PHP manual sources. -7. Publish the announce on www.php.net as well (for all releases, alpha, RCs or other) - Rolling a stable release ------------------------ -1. Check windows snapshot builder logs (http://snaps.php.net/win32/snapshot-STABLE.log f.e.) - -2. Bump the version numbers in ``main/php_version.h``, ``configure.in`` and possibly ``NEWS``. +1. Checkout your release branch, you should have created when releasing previous RC +and bump the version numbers in ``main/php_version.h``, ``configure.in`` and possibly ``NEWS``. -3. **Merge** all related sections in NEWS (f.e. merge the 5.4.1RC1 and 5.4.0 sections) +2. If a CVE commit needs to be merged to the release, then have it commited to +the base branches and merged upwards as usual (f.e commit the CVE fix to 5.3, +merge to 5.4, 5.5 etc...). Then you can cherry-pick it in your release branch. +Don't forget to update NEWS manually in an extra commit then. -4. Commit those changes +3. Commit those changes -5. run the "scripts/dev/credits" script in php-src and commit the changes in the +4. run the "scripts/dev/credits" script in php-src and commit the changes in the credits files in ext/standard. -6. tag the repository with the version f.e. "``git tag -s php-5.4.1``" -(of course, you need to change that to the version you're rolling an RC for). -When making 5.X release, you need to tag the Zend directory separately!! +5. Compile and make test, with and without ZTS, using the right Bison version +(for example, for 5.5, Bison 2.4.1 is used) -7. Bump up the version numbers in ``main/php_version.h``, ``configure.in`` and -possibly ``NEWS`` again, to the **next** version. F.e. if the release candidate -was "5.4.1RC1" then the new one should be "5.4.1RC2-dev" - regardless if we get -a new RC or not. This is to make sure ``version_compare()`` can correctly work. +6. Check ./sapi/cli/php -v output for version matching. -8. Commit those changes +7. tag the repository with the version f.e. "``git tag -s php-5.4.1``" -9. Log in onto the snaps box and go into the correct tree (f.e. the PHP-5.4 -branch if you're rolling 5.5.x releases). +8. Push the tag f.e. "``git push origin php-5.4.1``" -10. You do not have to update the tree, but of course you can with "``git pull -origin <branch>``". +9. run: ``PHPROOT=. ./makedist php 5.4.1``, this will export the tag, create configure +and build three tarballs (gz, bz2 and xz). +Check if the pear files are updated (phar). -11. run: ``./makedist php 5.4.1``, this will export the tree, create configure -and build two tarballs (one gz and one bz2). +10. Generate the GPG signature files for the archives. + ``gpg -u YOUREMAIL --armor --detach-sign php-X.Y.Z.tar.xxx`` -12. Commit those two tarballs to web/php-distributions.git, then update the git - submodule reference in web/php.git: - git submodule init; +11. Commit and push all the tarballs and signature files to web/php-distributions.git, + then update the git submodule reference in web/php.git: + ``git submodule init; git submodule update; cd distributions; git pull origin master; cd ..; git commit distributions; - git push; - -13. Once the release has been tagged, contact the PHP Windows development team -(internals-win@lists.php.net) so that Windows binaries can be created. Once -those are made, they should be committed to SVN too. - -14. Check if the pear files are updated (phar for 5.1+ or run pear/make-pear-bundle.php with 4.4) + git push;`` +This is to fetch the last commit id from php-distributions.git and commit this +last commit id to web/php.git, then, mirrors will now sync -15. When making a final release, also remind the PHP Windows development team -(internals-win@lists.php.net) to prepare the installer packages for Win32. +12. Once the release has been tagged, contact the PHP Windows development team +(internals-win@lists.php.net) so that Windows binaries can be created. Getting the stable release announced ------------------------------------ 1. Run the bumpRelease script for phpweb on your local checkout - a. ``php bin/bumpRelease 5`` (or ``php bin/bumpRelease 4`` for PHP4) + a. ``php bin/bumpRelease 5`` to create the release file (releases/x_y_z.php) + The release announcement file should list in detail security fixes and + changes in behavior (whether due to a bug fix or not). b. In case multiple PHP minor versions are in active development you have to manually copy the old information to include/releases.inc @@ -206,7 +207,13 @@ Getting the stable release announced f. if the windows builds aren't ready yet prefix the "windows" key with a dot (".windows") -3. Update the ChangeLog file for the given major version +3. Update phpweb/include/releases.php with the old release info + (updates the download archives) + +4. Update php-qa/include/release-qa.php and add the next version as an QARELEASE + (prepare for next RC) + +5. Update the ChangeLog file for the given major version f.e. ``ChangeLog-5.php`` from the NEWS file a. go over the list and put every element on one line @@ -226,19 +233,10 @@ f.e. ``ChangeLog-5.php`` from the NEWS file IV. ``s/Fixed PECL bug #\([0-9]\+\)/<?php peclbugfix(\1); ?>/`` V. ``s/FR #\([0-9]\+\)/FR <?php bugl(\1); ?>/`` + + e. You may want to try php-web/bin/news2html to automate this task -4. ``cp releases/5_4_0.php releases/5_4_1.php`` - -5. ``git add releases/5_4_1.php`` - -6. Update the ``releases/*.php`` file with relevant data. The release -announcement file should list in detail: - - a. security fixes, - - b. changes in behavior (whether due to a bug fix or not) - -7. Add a short notice to phpweb stating that there is a new release, and +6. Add a short notice to phpweb stating that there is a new release, and highlight the major important things (security fixes) and when it is important to upgrade. @@ -246,7 +244,11 @@ to upgrade. b. Add the content for the news entry -8. Commit all the changes. +7. **Check mirrors have been synced before announcing or pushing news** + Try, f.e. http://www.php.net/get/php-5.5.1.tar.bz2/from/a/mirror + Try several mirrors, mirrors may update slowly (may take an hour) + +8. Commit all the changes to their respective git repos 9. Wait an hour or two, then send a mail to php-announce@lists.php.net, php-general@lists.php.net and internals@lists.php.net with a text similar to |