Skip to content

Commit 3eb2b1a

Browse files
author
Julien Pauli
committed
Updated release process
1 parent 6f73931 commit 3eb2b1a

File tree

1 file changed

+79
-77
lines changed

1 file changed

+79
-77
lines changed

README.RELEASE_PROCESS

Lines changed: 79 additions & 77 deletions
Original file line numberDiff line numberDiff line change
@@ -8,15 +8,16 @@ General notes and tips
88
1. Do not release on Fridays, Saturdays or Sundays
99
because the sysadmins can not upgrade stuff then.
1010

11-
2. Package the day before a release. So if the release is to be on Thursday,
12-
package on Wednesday.
11+
2. Package two days before a release. So if the release is to be on Thursday,
12+
package on Tuesday. Think about timezones as well.
1313

1414
3. Ensure that Windows builds will work before packaging
1515

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.
16+
4. Follow all steps to the letter. When unclear ask previous RM's (David/Julien/
17+
Johannes/Stas/Derick/Ilia) before proceeding. Ideally make sure that for the
18+
first releases one of the previous RM's is around to answer questions. For the
19+
steps related to the php/QA/bug websites try to have someone from the webmaster
20+
team (Bjori) on hand.
2021

2122
5. Verify the tags to be extra sure everything was tagged properly.
2223

@@ -50,38 +51,44 @@ Rolling a non stable release (alpha/beta/RC)
5051
2. run the "scripts/dev/credits" script in php-src and commit the changes in the
5152
credits files in ext/standard.
5253

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.
54+
3. Checkout the release branch for this release (e.g., PHP-5.4.2) from the main branch.
5555

56-
4. Commit those changes and note the revision id.
56+
4. Bump the version numbers in ``main/php_version.h``, ``configure.in`` and possibly ``NEWS``.
57+
Do not use abbreviations for alpha and beta. Do not use dashes, you should
58+
``#define PHP_VERSION "5.4.22RC1"`` and not ``#define PHP_VERSION "5.4.22-RC1"``
5759

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+
5. Compile and make test, with and without ZTS, using the right Bison version
61+
(for example, for 5.5, Bison 2.4.1 is used)
6062

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.
63+
6. Check ./sapi/cli/php -v output for version matching.
6664

67-
7. Commit those changes
65+
7. If all is right, commit the changes to the release branch with ``git commit -a``.
6866

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).
67+
8. Tag the repository release branch with the version, e.g.:
68+
``git tag -u YOURKEYID php-5.4.2RC2``
7169

72-
9. You do not have to update the tree, but of course you can with "``svn up``".
70+
9. Bump the version numbers in ``main/php_version.h``, ``configure.in`` and ``NEWS``
71+
in the *main* branch (PHP-5.4 for example) to prepare for the **next** version.
72+
F.e. if the RC is "5.4.1RC1" then the new one should be "5.4.2-dev" - regardless if we get
73+
a new RC or not. This is to make sure ``version_compare()`` can correctly work.
74+
Commit the changes to the main branch.
75+
76+
10. Push the changes to the main repo, the tag, the main branch and the release branch :
77+
``git push --tags origin HEAD``
78+
``git push origin {main branch}``
79+
``git push origin {release branch}``
7380

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).
81+
11. run: ``PHPROOT=. ./makedist 5.4.2RC2``, this will export the tree, create configure
82+
and build three tarballs (gz, bz2 and xz).
7683

77-
11. Copy those two tarballs to www.php.net, in your homedir there should be a
84+
12. Copy those tarballs (scp, rsync) to downloads.php.net, in your homedir there should be a
7885
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.
86+
MD5 sums. If you do not have this directory, talk to Derick or Dan.
8087

81-
12. Now the RC can be found on http://downloads.php.net/yourname,
88+
13. Now the RC can be found on http://downloads.php.net/yourname,
8289
f.e. http://downloads.php.net/derick/
8390

84-
13. Once the release has been tagged, contact the PHP Windows development team
91+
14. Once the release has been tagged, contact the PHP Windows development team
8592
(internals-win@lists.php.net) so that Windows binaries can be created. Once
8693
those are made, they should be placed into the same directory as the source snapshots.
8794

@@ -113,9 +120,9 @@ Derick) run the following commands for you:
113120

114121
Note: Remember to update the MD5 checksum information.
115122

116-
4. Update ``php.git/include/version.inc`` (x=major version number)
123+
4. Update ``web/php.git/include/version.inc`` (x=major version number)
117124

118-
a. ``$PHP_x_RC`` = "5.3.0RC1"
125+
a. ``$PHP_x_RC`` = "5.4.0RC1" (should be set to "false" before)
119126

120127
b. ``$PHP_x_RC_DATE`` = "06 September 2007"
121128

@@ -126,67 +133,61 @@ Derick) run the following commands for you:
126133
6. For the first RC, write the doc team (phpdoc@lists.php.net) about updating the
127134
INSTALL and win32/install.txt files which are generated from the PHP manual sources.
128135

129-
7. Publish the announce on www.php.net as well (for all releases, alpha, RCs or other)
130-
131136
Rolling a stable release
132137
------------------------
133138

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``.
139+
1. Checkout your release branch, you should have created when releasing previous RC
140+
and bump the version numbers in ``main/php_version.h``, ``configure.in`` and possibly ``NEWS``.
137141

138-
3. **Merge** all related sections in NEWS (f.e. merge the 5.4.1RC1 and 5.4.0 sections)
142+
2. If a CVE commit needs to be merged to the release, then have it commited to
143+
the base branches and merged upwards as usual (f.e commit the CVE fix to 5.3,
144+
merge to 5.4, 5.5 etc...). Then you can cherry-pick it in your release branch.
145+
Don't forget to update NEWS manually in an extra commit then.
139146

140-
4. Commit those changes
147+
3. Commit those changes
141148

142-
5. run the "scripts/dev/credits" script in php-src and commit the changes in the
149+
4. run the "scripts/dev/credits" script in php-src and commit the changes in the
143150
credits files in ext/standard.
144151

145-
6. tag the repository with the version f.e. "``git tag -s php-5.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!!
152+
5. Compile and make test, with and without ZTS, using the right Bison version
153+
(for example, for 5.5, Bison 2.4.1 is used)
148154

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 "5.4.1RC1" then the new one should be "5.4.1RC2-dev" - regardless if we get
152-
a new RC or not. This is to make sure ``version_compare()`` can correctly work.
155+
6. Check ./sapi/cli/php -v output for version matching.
153156

154-
8. Commit those changes
157+
7. tag the repository with the version f.e. "``git tag -s php-5.4.1``"
155158

156-
9. Log in onto the snaps box and go into the correct tree (f.e. the PHP-5.4
157-
branch if you're rolling 5.5.x releases).
159+
8. Push the tag f.e. "``git push origin php-5.4.1``"
158160

159-
10. You do not have to update the tree, but of course you can with "``git pull
160-
origin <branch>``".
161+
9. run: ``PHPROOT=. ./makedist php 5.4.1``, this will export the tag, create configure
162+
and build three tarballs (gz, bz2 and xz).
163+
Check if the pear files are updated (phar).
161164

162-
11. run: ``./makedist php 5.4.1``, this will export the tree, create configure
163-
and build two tarballs (one gz and one bz2).
165+
10. Generate the GPG signature files for the archives.
166+
``gpg -u YOUREMAIL --armor --detach-sign php-X.Y.Z.tar.xxx``
164167

165-
12. Commit those two tarballs to web/php-distributions.git, then update the git
166-
submodule reference in web/php.git:
167-
git submodule init;
168+
11. Commit and push all the tarballs and signature files to web/php-distributions.git,
169+
then update the git submodule reference in web/php.git:
170+
``git submodule init;
168171
git submodule update;
169172
cd distributions;
170173
git pull origin master;
171174
cd ..;
172175
git commit distributions;
173-
git push;
174-
175-
13. Once the release has been tagged, contact the PHP Windows development team
176-
(internals-win@lists.php.net) so that Windows binaries can be created. Once
177-
those are made, they should be committed to SVN too.
178-
179-
14. Check if the pear files are updated (phar for 5.1+ or run pear/make-pear-bundle.php with 4.4)
176+
git push;``
177+
This is to fetch the last commit id from php-distributions.git and commit this
178+
last commit id to web/php.git, then, mirrors will now sync
180179

181-
15. When making a final release, also remind the PHP Windows development team
182-
(internals-win@lists.php.net) to prepare the installer packages for Win32.
180+
12. Once the release has been tagged, contact the PHP Windows development team
181+
(internals-win@lists.php.net) so that Windows binaries can be created.
183182

184183
Getting the stable release announced
185184
------------------------------------
186185

187186
1. Run the bumpRelease script for phpweb on your local checkout
188187

189-
a. ``php bin/bumpRelease 5`` (or ``php bin/bumpRelease 4`` for PHP4)
188+
a. ``php bin/bumpRelease 5`` to create the release file (releases/x_y_z.php)
189+
The release announcement file should list in detail security fixes and
190+
changes in behavior (whether due to a bug fix or not).
190191

191192
b. In case multiple PHP minor versions are in active development you have
192193
to manually copy the old information to include/releases.inc
@@ -206,7 +207,13 @@ Getting the stable release announced
206207

207208
f. if the windows builds aren't ready yet prefix the "windows" key with a dot (".windows")
208209

209-
3. Update the ChangeLog file for the given major version
210+
3. Update phpweb/include/releases.php with the old release info
211+
(updates the download archives)
212+
213+
4. Update php-qa/include/release-qa.php and add the next version as an QARELEASE
214+
(prepare for next RC)
215+
216+
5. Update the ChangeLog file for the given major version
210217
f.e. ``ChangeLog-5.php`` from the NEWS file
211218

212219
a. go over the list and put every element on one line
@@ -226,27 +233,22 @@ f.e. ``ChangeLog-5.php`` from the NEWS file
226233
IV. ``s/Fixed PECL bug #\([0-9]\+\)/<?php peclbugfix(\1); ?>/``
227234

228235
V. ``s/FR #\([0-9]\+\)/FR <?php bugl(\1); ?>/``
236+
237+
e. You may want to try php-web/bin/news2html to automate this task
229238

230-
4. ``cp releases/5_4_0.php releases/5_4_1.php``
231-
232-
5. ``git add releases/5_4_1.php``
233-
234-
6. Update the ``releases/*.php`` file with relevant data. The release
235-
announcement file should list in detail:
236-
237-
a. security fixes,
238-
239-
b. changes in behavior (whether due to a bug fix or not)
240-
241-
7. Add a short notice to phpweb stating that there is a new release, and
239+
6. Add a short notice to phpweb stating that there is a new release, and
242240
highlight the major important things (security fixes) and when it is important
243241
to upgrade.
244242

245243
a. Call php bin/createNewsEntry in your local phpweb checkout
246244

247245
b. Add the content for the news entry
248246

249-
8. Commit all the changes.
247+
7. **Check mirrors have been synced before announcing or pushing news**
248+
Try, f.e. http://www.php.net/get/php-5.5.1.tar.bz2/from/a/mirror
249+
Try several mirrors, mirrors may update slowly (may take an hour)
250+
251+
8. Commit all the changes to their respective git repos
250252

251253
9. Wait an hour or two, then send a mail to php-announce@lists.php.net,
252254
php-general@lists.php.net and internals@lists.php.net with a text similar to

0 commit comments

Comments
 (0)