You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.RELEASE_PROCESS
+79-77Lines changed: 79 additions & 77 deletions
Original file line number
Diff line number
Diff line change
@@ -8,15 +8,16 @@ General notes and tips
8
8
1. Do not release on Fridays, Saturdays or Sundays
9
9
because the sysadmins can not upgrade stuff then.
10
10
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.
13
13
14
14
3. Ensure that Windows builds will work before packaging
15
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.
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.
20
21
21
22
5. Verify the tags to be extra sure everything was tagged properly.
22
23
@@ -50,38 +51,44 @@ Rolling a non stable release (alpha/beta/RC)
50
51
2. run the "scripts/dev/credits" script in php-src and commit the changes in the
51
52
credits files in ext/standard.
52
53
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.
55
55
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"``
57
59
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)
60
62
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.
66
64
67
-
7. Commit those changes
65
+
7. If all is right, commit the changes to the release branch with ``git commit -a``.
68
66
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``
71
69
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}``
73
80
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).
76
83
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
78
85
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.
80
87
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,
82
89
f.e. http://downloads.php.net/derick/
83
90
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
85
92
(internals-win@lists.php.net) so that Windows binaries can be created. Once
86
93
those are made, they should be placed into the same directory as the source snapshots.
87
94
@@ -113,9 +120,9 @@ Derick) run the following commands for you:
113
120
114
121
Note: Remember to update the MD5 checksum information.
115
122
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)
117
124
118
-
a. ``$PHP_x_RC`` = "5.3.0RC1"
125
+
a. ``$PHP_x_RC`` = "5.4.0RC1" (should be set to "false" before)
119
126
120
127
b. ``$PHP_x_RC_DATE`` = "06 September 2007"
121
128
@@ -126,67 +133,61 @@ Derick) run the following commands for you:
126
133
6. For the first RC, write the doc team (phpdoc@lists.php.net) about updating the
127
134
INSTALL and win32/install.txt files which are generated from the PHP manual sources.
128
135
129
-
7. Publish the announce on www.php.net as well (for all releases, alpha, RCs or other)
130
-
131
136
Rolling a stable release
132
137
------------------------
133
138
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``.
137
141
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.
139
146
140
-
4. Commit those changes
147
+
3. Commit those changes
141
148
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
143
150
credits files in ext/standard.
144
151
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)
148
154
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.
153
156
154
-
8. Commit those changes
157
+
7. tag the repository with the version f.e. "``git tag -s php-5.4.1``"
155
158
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``"
158
160
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).
161
164
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.
0 commit comments