[BACK]Return to README.RELEASE_PROCESS CVS log [TXT] [DIR] Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / php

Diff for /embedaddon/php/README.RELEASE_PROCESS between versions 1.1.1.1 and 1.1.1.4

version 1.1.1.1, 2012/02/21 23:47:51 version 1.1.1.4, 2014/06/15 20:03:41
Line 8  General notes and tips Line 8  General notes and tips
 1. Do not release on Fridays, Saturdays or Sundays  1. Do not release on Fridays, Saturdays or Sundays
 because the sysadmins can not upgrade stuff then.  because the sysadmins can not upgrade stuff then.
   
2. Package the day before a release. So if the release is to be on Thursday,2. Package two days before a release. So if the release is to be on Thursday,
package on Wednesday.package on Tuesday. Think about timezones as well.
   
 3. Ensure that Windows builds will work before packaging  3. Ensure that Windows builds will work before packaging
   
4. Follow all steps to the letter. When unclear ask previous RM's (Derick/Ilia)4. Follow all steps to the letter. When unclear ask previous RM's (David/Julien/
before proceeding. Ideally make sure that for the first releases one of theJohannes/Stas/Derick/Ilia) before proceeding. Ideally make sure that for the
previous RM's is around to answer questions. For the steps related to thefirst releases one of the previous RM's is around to answer questions. For the
php/QA/bug websites try to have someone from the webmaster team (Bjori) on hand.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.  5. Verify the tags to be extra sure everything was tagged properly.
   
Line 50  Rolling a non stable release (alpha/beta/RC) Line 51  Rolling a non stable release (alpha/beta/RC)
 2. run the "scripts/dev/credits" script in php-src and commit the changes in the  2. run the "scripts/dev/credits" script in php-src and commit the changes in the
 credits files in ext/standard.  credits files in ext/standard.
   
3. Bump the version numbers in ``main/php_version.h``, ``configure.in`` and possibly ``NEWS``.3. Checkout the release branch for this release (e.g., PHP-5.4.2) from the main branch.
Do not use abbreviations for alpha and beta. 
   
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``"5. Compile and make test, with and without ZTS, using the right Bison version
(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.(for example, for 5.5, Bison 2.4.1 is used)
   
6. Bump up the version numbers in ``main/php_version.h``, ``configure.in``6. Check ./sapi/cli/php -v output for version matching.
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. 
   
7. Commit those changes7. 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_48. Tag the repository release branch with the version, e.g.: 
branch if you're rolling 4.4.x releases).``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. run: ``./makedist php 4.4.1RC1``, this will export the tree, create configure10. Push the changes to the main repo, the tag, the main branch and the release branch :
and build two tarballs (one gz and one bz2).``git push --tags origin HEAD``
 ``git push origin {main branch}``
 ``git push origin {release branch}``
   
11. Copy those two tarballs to www.php.net, in your homedir there should be a11. run: ``PHPROOT=. ./makedist 5.4.2RC2``, this will export the tree, create configure
 and build three tarballs (gz, bz2 and xz).
 
 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  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/  f.e. http://downloads.php.net/derick/
   
13. Once the release has been tagged, contact the PHP Windows development team14. 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  (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.  those are made, they should be placed into the same directory as the source snapshots.
   
Line 94  pointing out "the location of the release" and "the po Line 101  pointing out "the location of the release" and "the po
 either the next RC, or the final release".  either the next RC, or the final release".
   
 2. Send an email (see example here http://news.php.net/php.pear.qa/5201) **To**  2. Send an email (see example here http://news.php.net/php.pear.qa/5201) **To**
``php-qa@lists.php.net`` and ``primary-qa-tests@lists.php.net``.``php-qa@lists.php.net`` and ``primary-qa-tester@lists.php.net``.
 This email is to notify the selected projects about a new release so that they  This email is to notify the selected projects about a new release so that they
 can make sure their projects keep working. Make sure that you have been setup  can make sure their projects keep working. Make sure that you have been setup
as a moderator for ``primary-qa-tests@lists.php.net`` by having someone (Wez,as a moderator for ``primary-qa-tester@lists.php.net`` by having someone (Hannes, Dan,
 Derick) run the following commands for you:  Derick) run the following commands for you:
   
 ``ssh lists.php.net``  ``ssh lists.php.net``
   
 ``sudo -u ezmlm ezmlm-sub ~ezmlm/primary-qa-tester/mod moderator-email-address``  ``sudo -u ezmlm ezmlm-sub ~ezmlm/primary-qa-tester/mod moderator-email-address``
   
3. Update ``web/qa/trunk/include/release-qa.php`` with the appropriate information.3. Update ``qa.git/include/release-qa.php`` with the appropriate information.
    See the documentation within release-qa.php for more information, but all releases     See the documentation within release-qa.php for more information, but all releases
    and RCs are configured here. Only $QA_RELEASES needs to be edited.     and RCs are configured here. Only $QA_RELEASES needs to be edited.
   
Line 113  Derick) run the following commands for you: Line 120  Derick) run the following commands for you:
   
    Note: Remember to update the MD5 checksum information.     Note: Remember to update the MD5 checksum information.
   
4. Update ``web/php/trunk/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"   b. ``$PHP_x_RC_DATE`` = "06 September 2007"
   
5. Commit those changes:5. Commit and push those changes:
   
 a. ``svn commit web/qa/trunk web/php-bugs/trunk web/php/trunk`` a. ``git commit -a && git push origin master``
   
 6. For the first RC, write the doc team (phpdoc@lists.php.net) about updating the  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.  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  Rolling a stable release
 ------------------------  ------------------------
   
1. Check windows snapshot builder logs (http://snaps.php.net/win32/snapshot-STABLE.log f.e.)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``.
   
2. Bump the version numbers in ``main/php_version.h``, ``configure.in`` and possibly ``NEWS``.2. If a CVE commit needs to be merged to the release, then have it committed 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.
   
3. **Merge** all related sections in NEWS (f.e. merge the 4.4.1RC1 and 4.4.0 sections)3. Commit those changes
   
4. Commit those changes4. run the "scripts/dev/credits" script in php-src and commit the changes in the
 
5. run the "scripts/dev/credits" script in php-src and commit the changes in the 
 credits files in ext/standard.  credits files in ext/standard.
   
6. tag the repository with the version f.e. "``cvs tag php_4_4_1``"5. Compile and make test, with and without ZTS, using the right Bison version
(of course, you need to change that to the version you're rolling an RC for).(for example, for 5.5, Bison 2.4.1 is used)
When making 5.X release, you need to tag the Zend directory separately!! 
   
7. Bump up the version numbers in ``main/php_version.h``, ``configure.in`` and6. Check ./sapi/cli/php -v output for version matching.
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. 
   
8. Commit those changes7. 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_4_48. Push the tag f.e. "``git push origin php-5.4.1``"
branch if you're rolling 4.4.x releases). 
   
10. You do not have to update the tree, but of course you can with "``cvs up -dP``".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 4.4.1``, this will export the tree, create configure10. Generate the GPG signature files for the archives.
and build two tarballs (one gz and one bz2).  ``gpg -u YOUREMAIL --armor --detach-sign php-X.Y.Z.tar.xxx``
   
12. Commit those two tarballs to CVS (phpweb/distributions)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;``
 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
   
13. Once the release has been tagged, contact the PHP Windows development team12. 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(internals-win@lists.php.net) so that Windows binaries can be created.
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)  
   
 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.  
   
 Getting the stable release announced  Getting the stable release announced
 ------------------------------------  ------------------------------------
   
 1. Run the bumpRelease script for phpweb on your local checkout  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
   
 2. Edit ``phpweb/include/version.inc`` and change (X=major release number):  2. Edit ``phpweb/include/version.inc`` and change (X=major release number):
   
  a. ``$PHP_X_VERSION`` to the correct version   a. ``$PHP_X_VERSION`` to the correct version
Line 194  Getting the stable release announced Line 207  Getting the stable release announced
   
  f. if the windows builds aren't ready yet prefix the "windows" key with a dot (".windows")   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 version3. Update phpweb/include/releases.php with the old release info
f.e. ``ChangeLog-4.php`` from the NEWS file  (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   a. go over the list and put every element on one line
   
  b. check for &, < and > and escape them if necessary   b. check for &, < and > and escape them if necessary
Line 214  f.e. ``ChangeLog-4.php`` from the NEWS file Line 233  f.e. ``ChangeLog-4.php`` from the NEWS file
   IV. ``s/Fixed PECL bug #\([0-9]\+\)/<?php peclbugfix(\1); ?>/``    IV. ``s/Fixed PECL bug #\([0-9]\+\)/<?php peclbugfix(\1); ?>/``
   
   V. ``s/FR #\([0-9]\+\)/FR <?php bugl(\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/4_4_0.php releases/4_4_1.php``6. Add a short notice to phpweb stating that there is a new release, and
 
5. ``cvs add releases/4_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 
 highlight the major important things (security fixes) and when it is important  highlight the major important things (security fixes) and when it is important
 to upgrade.  to upgrade.
   
Line 234  to upgrade. Line 244  to upgrade.
   
  b. Add the content for the news entry   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,  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  php-general@lists.php.net and internals@lists.php.net with a text similar to
 http://news.php.net/php.internals/17222.  http://news.php.net/php.internals/17222.
   
 10. Update ``php-bugs-web/include/functions.php`` to include the new version  
 number, and remove the RC from there.  
   
 11. Update ``qaweb/include/release-qa.php``  
   
  - Update $QA_RELEASES with the appropriate information, which means bumping  
    the version number to an upcoming version.   
   
    Example: If PHP 5.3.7 is being released, then PHP 5.3.8 is the next QA version,  
    so replace 5.3.7 with 5.3.8 within $QA_RELEASES.  
   
 Re-releasing the same version (or -pl)  Re-releasing the same version (or -pl)
 --------------------------------------  --------------------------------------
Removed from v.1.1.1.1  
changed lines
  Added in v.1.1.1.4

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>