You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

228 lines
8.1 KiB

  1. =======================
  2. PHP Release Process
  3. =======================
  4. General notes and tips
  5. ----------------------
  6. 1. Do not release on Fridays, Saturdays or Sundays
  7. because the sysadmins can not upgrade stuff then.
  8. 2. Package the day before a release. So if the release is to be on Thursday,
  9. package on Wednesday.
  10. 3. Ensure that Windows builds will work before packaging
  11. 4. Follow all steps to the letter. When unclear ask previous RM's (Derick/Ilia)
  12. before proceeding. Ideally make sure that for the first releases one of the
  13. previous RM's is around to answer questions. For the steps related to the
  14. php/QA/bug websites try to have someone from the webmaster team (Bjori) on hand.
  15. 5. Verify the tags to be extra sure everything was tagged properly.
  16. Rolling a non stable release (alpha/beta/RC)
  17. --------------------------------------------
  18. 1. Check windows snapshot builder logs (http://snaps.php.net/win32/snapshot-STABLE.log f.e.)
  19. 2. Bump the version numbers in ``main/php_version.h``, ``configure.in`` and possibly ``NEWS``.
  20. Do not use abbreviations for alpha and beta.
  21. 3. Commit those changes
  22. 4. tag the repository with the version f.e. "``cvs tag php_4_4_1RC1``"
  23. (of course, you need to change that to the version you're rolling an RC for).
  24. 5. Bump up the version numbers in ``main/php_version.h``, ``configure.in``
  25. and possibly ``NEWS`` again, to the **next** version. F.e. if the release
  26. candidate was "4.4.1RC1" then the new one should be "4.4.1RC2-dev" - regardless
  27. if we get a new RC or not. This is to make sure ``version_compare()`` can
  28. correctly work.
  29. 6. Commit those changes
  30. 7. Log in onto the snaps box and go into the correct tree (f.e. the PHP_4_4
  31. branch if you're rolling 4.4.x releases).
  32. 8. You do not have to update the tree, but of course you can with "``cvs up -dP``".
  33. 9. run: ``./makedist php 4.4.1RC1``, this will export the tree, create configure
  34. and build two tarballs (one gz and one bz2).
  35. 10. Copy those two tarballs to www.php.net, in your homedir their should be a
  36. directory "downloads/". Copy them into there, so that the system can generate
  37. MD5 sums. If you do not have this directory, talk to Derick.
  38. 11. Now the RC can be found on http://downloads.php.net/yourname,
  39. f.e. http://downloads.php.net/derick/
  40. 12. Once the release has been tagged, contact the PHP Windows development team
  41. (internals-win@lists.php.net) so that Windows binaries can be created. Once
  42. those are made, they should be placed into the same directory as the source snapshots.
  43. Getting the non stable release announced
  44. ----------------------------------------
  45. 1. Send an email (see example here: http://news.php.net/php.internals/19486)
  46. **To** ``internals@lists.php.net`` and ``php-general@lists.php.net`` lists
  47. pointing out "the location of the release" and "the possible release date of
  48. either the next RC, or the final release".
  49. 2. Send an email (see example here http://news.php.net/php.qa/26069) **To**
  50. ``php-qa@lists.php.net`` and **CC** ``primary-qa-tests@lists.php.net``.
  51. This email is to notify the selected projects about a new RC so that they can
  52. make sure their projects keep working. Make sure that you have been setup
  53. as a moderator for ``primary-qa-tests@lists.php.net`` by having someone (Wez,
  54. Derick) run the following commands for you:
  55. ``ssh lists.php.net``
  56. ``sudo -u ezmlm ezmlm-sub ~ezmlm/primary-qa-tester/mod moderator-email-address``
  57. 3. Update the MD5 sums in ``qaweb/include/rc-md5sums.txt``.
  58. 4. Update in ``qaweb/include/release-qa.php`` constants with the new RC and
  59. commit this.
  60. a. ``$BUILD_TEST_RELEASES`` = array("4.4.7RC1", "5.2.2RC1")
  61. b. ``$CURRENT_QA_RELEASE_4`` = "4.4.7RC1" (``$CURRENT_QA_RELEASE_5`` for PHP5)
  62. c. ``$RELEASE_PROCESS`` = array(4 => true, 5 => true)
  63. 1. Update in ``php-bugs-web/include/functions.inc`` the ``show_version_option``
  64. function to include the new RC and commit.
  65. 2. Run the bumpRelease script for phpweb in your local checkout
  66. a. ``php bin/bumpRelease 5`` (or ``php bin/bumpRelease 4`` for PHP4)
  67. 3. Update ``phpweb/include/version.inc`` (x=major version number)
  68. a. ``$PHP_x_RC`` = "5.3.0RC1"
  69. b. ``$PHP_x_RC_DATE`` = "06 September 2007"
  70. 4. Commit those changes:
  71. a. ``cvs commit include/version.inc include/releases.inc``
  72. Rolling a stable release
  73. ------------------------
  74. 1. Check windows snapshot builder logs (http://snaps.php.net/win32/snapshot-STABLE.log f.e.)
  75. 2. Bump the version numbers in ``main/php_version.h``, ``configure.in`` and possibly ``NEWS``.
  76. 3. **Merge** all related sections in NEWS (f.e. merge the 4.4.1RC1 and 4.4.0 sections)
  77. 4. Commit those changes
  78. 5. tag the repository with the version f.e. "``cvs tag php_4_4_1``"
  79. (of course, you need to change that to the version you're rolling an RC for).
  80. When making 5.X release, you need to tag the Zend directory separately!!
  81. 6. Bump up the version numbers in ``main/php_version.h``, ``configure.in`` and
  82. possibly ``NEWS`` again, to the **next** version. F.e. if the release candidate
  83. was "4.4.1RC1" then the new one should be "4.4.1RC2-dev" - regardless if we get
  84. a new RC or not. This is to make sure ``version_compare()`` can correctly work.
  85. 7. Commit those changes
  86. 8. Log in onto the snaps box and go into the correct tree (f.e. the PHP_4_4
  87. branch if you're rolling 4.4.x releases).
  88. 9. You do not have to update the tree, but of course you can with "``cvs up -dP``".
  89. 10. run: ``./makedist php 4.4.1``, this will export the tree, create configure
  90. and build two tarballs (one gz and one bz2).
  91. 11. Commit those two tarballs to CVS (phpweb/distributions)
  92. 12. Once the release has been tagged, contact the PHP Windows development team
  93. (internals-win@lists.php.net) so that Windows binaries can be created. Once
  94. those are made, they should be committed to CVS too.
  95. 13. Check if the pear files are updated (phar for 5.1+ or run pear/make-pear-bundle.php with 4.4)
  96. 14. When making a final release, also remind the PHP Windows development team
  97. (internals-win@lists.php.net) to prepare the installer packages for Win32.
  98. Getting the stable release announced
  99. ------------------------------------
  100. 1. Run the bumpRelease script for phpweb on your local checkout
  101. a. ``php bin/bumpRelease 5`` (or ``php bin/bumpRelease 4`` for PHP4)
  102. 2. Edit ``phpweb/include/version.inc`` and change (X=major release number):
  103. a. ``$PHP_X_VERSION`` to the correct version
  104. b. ``$PHP_X_DATE`` to the release date
  105. c. ``$PHP_X_MD5`` array and update all the md5 sums
  106. d. set ``$PHP_X_RC`` to false!
  107. e. Make sure there are no outdated "notes" or edited "date" keys in the
  108. ``$RELEASES[X][$PHP_X_VERSION]["source"]`` array
  109. f. if the windows builds aren't ready yet prefix the "windows" key with a dot (".windows")
  110. 3. Update the ChangeLog file for the given major version
  111. f.e. ``ChangeLog-4.php`` from the NEWS file
  112. a. go over the list and put every element on one line
  113. b. check for &, < and > and escape them if necessary
  114. c. remove all the names at the ends of lines
  115. d. for marking up, you can do the following (with VI):
  116. I. ``s/^- /<li>/``
  117. II. ``s/$/<\/li>/``
  118. III. ``s/Fixed bug #\([0-9]\+\)/<?php bugfix(\1); ?>/``
  119. 4. ``cp releases/4_4_0.php releases/4_4_1.php``
  120. 5. ``cvs add releases/4_4_1.php``
  121. 6. Update the ``releases/*.php`` file with relevant data. The release
  122. announcement file should list in detail:
  123. a. security fixes,
  124. b. changes in behavior (whether due to a bug fix or not)
  125. 7. Add a short notice to phpweb stating that there is a new release, and
  126. highlight the major important things (security fixes) and when it is important
  127. to upgrade.
  128. a. Call php bin/createNewsEntry in your local phpweb checkout
  129. b. Add the content for the news entry
  130. 8. Commit all the changes.
  131. 9. Wait an hour or two, then send a mail to php-announce@lists.php.net,
  132. php-general@lists.php.net and internals@lists.php.net with a text similar to
  133. http://news.php.net/php.internals/17222.
  134. 10. Update ``php-bugs-web/include/functions.php`` to include the new version
  135. number, and remove the RC from there.
  136. 11. Update ``qaweb/include/release-qa.php``
  137. a. Update the $BUILD_TEST_RELEASES array with the release name
  138. b. Update $RELEASE_PROCESS array (set to false)
  139. I. For PHP4: Set $CURRENT_QA_RELEASE_4 to false
  140. II. For PHP5: Set $CURRENT_QA_RELEASE_5 to false
  141. 12. Rebuild the English and Japanese docs (ask Derick)