forked from php/php-src
/
README.RELEASE_PROCESS
289 lines (183 loc) · 10.9 KB
/
README.RELEASE_PROCESS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
=======================
PHP Release Process
=======================
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.
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.
5. Verify the tags to be extra sure everything was tagged properly.
6. Moving extensions from/to PECL requires write acces to the destination.
Most developers should have this.
Moving extensions from php-src to PECL
- Checkout the pecl directory, most likely you want a sparse-root checkout
svn co --depth=empty https://svn.php.net/repository/pecl
- Create an directory for the extension incl. branch and tag structure,
no trunk at this point and commit this to svn
cd pecl; mkdir foo foo/tags foo/branches; svn add foo; svn commit
- Move the extension from php-src to the new location
svn mv https://svn.php.net/repository/php/php-src/trunk/ext/foo \
https://svn.php.net/repository/pecl/foo/trunk
If the extension is still usable or not dead, in cooperation with the extension
maintainers if any:
- create the pecl.php.net/foo package and its content, license, maintainer
- create the package.xml, commit
- release the package
For Moving extensions from PECL to php-src the svn mv has to be tone the other
way round.
Rolling a non stable release (alpha/beta/RC)
--------------------------------------------
1. Check windows snapshot builder logs (http://snaps.php.net/win32/snapshot-STABLE.log f.e.)
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.
4. Commit those changes and note the revision id.
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).
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.
7. Commit those changes
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).
9. You do not have to update the tree, but of course you can with "``svn up``".
10. run: ``./makedist php 4.4.1RC1``, this will export the tree, create configure
and build two tarballs (one gz and one bz2).
11. Copy those two tarballs to www.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.
12. 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
(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.
Getting the non stable release (alpha/beta/RC) announced
--------------------------------------------------------
1. Send an email (see example here: http://news.php.net/php.internals/19486)
**To** ``internals@lists.php.net`` and ``php-general@lists.php.net`` lists
pointing out "the location of the release" and "the possible release date of
either the next RC, or the final release".
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``.
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
as a moderator for ``primary-qa-tests@lists.php.net`` by having someone (Wez,
Derick) run the following commands for you:
``ssh lists.php.net``
``sudo -u ezmlm ezmlm-sub ~ezmlm/primary-qa-tester/mod moderator-email-address``
3. Update the MD5 sums in ``web/qa/trunk/include/rc-md5sums.txt`` (no empty lines, ordered by filename, odler version number first, .bz2 before .gz).
4. Update in ``web/qa/trunk/include/release-qa.php`` constants with the new RC and
commit this.
a. ``$BUILD_TEST_RELEASES`` = array("4.4.7RC1", "5.2.2RC1")
b. ``$CURRENT_QA_RELEASE_4`` = "4.4.7RC1" (``$CURRENT_QA_RELEASE_5`` for PHP5)
c. ``$RELEASE_PROCESS`` = array(4 => true, 5 => true)
1. Update in ``web/php-bugs/trunk/include/php_versions.php`` to include the new RC and commit.
2. Update ``web/php/trunk/include/version.inc`` (x=major version number)
a. ``$PHP_x_RC`` = "5.3.0RC1"
b. ``$PHP_x_RC_DATE`` = "06 September 2007"
3. Commit those changes:
a. ``svn commit web/qa/trunk web/php-bugs/trunk web/php/trunk``
4. 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.
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``.
3. **Merge** all related sections in NEWS (f.e. merge the 4.4.1RC1 and 4.4.0 sections)
4. Commit those changes
5. 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. "``cvs tag php_4_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!!
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 "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 changes
9. 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).
10. You do not have to update the tree, but of course you can with "``cvs up -dP``".
11. run: ``./makedist php 4.4.1``, this will export the tree, create configure
and build two tarballs (one gz and one bz2).
12. Commit those two tarballs to CVS (phpweb/distributions)
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 CVS 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
------------------------------------
1. Run the bumpRelease script for phpweb on your local checkout
a. ``php bin/bumpRelease 5`` (or ``php bin/bumpRelease 4`` for PHP4)
2. Edit ``phpweb/include/version.inc`` and change (X=major release number):
a. ``$PHP_X_VERSION`` to the correct version
b. ``$PHP_X_DATE`` to the release date
c. ``$PHP_X_MD5`` array and update all the md5 sums
d. set ``$PHP_X_RC`` to false!
e. Make sure there are no outdated "notes" or edited "date" keys in the
``$RELEASES[X][$PHP_X_VERSION]["source"]`` array
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
f.e. ``ChangeLog-4.php`` from the NEWS file
a. go over the list and put every element on one line
b. check for &, < and > and escape them if necessary
c. remove all the names at the ends of lines
d. for marking up, you can do the following (with VI):
I. ``s/^- /<li>/``
II. ``s/$/<\/li>/``
III. ``s/Fixed bug #\([0-9]\+\)/<?php bugfix(\1); ?>/``
IV. ``s/Fixed PECL bug #\([0-9]\+\)/<?php peclbugfix(\1); ?>/``
V. ``s/FR #\([0-9]\+\)/FR <?php bugl(\1); ?>/``
4. ``cp releases/4_4_0.php releases/4_4_1.php``
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
to upgrade.
a. Call php bin/createNewsEntry in your local phpweb checkout
b. Add the content for the news entry
8. Commit all the changes.
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
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``
a. Update the $BUILD_TEST_RELEASES array with the release name
b. Update $RELEASE_PROCESS array (set to false)
I. For PHP4: Set $CURRENT_QA_RELEASE_4 to false
II. For PHP5: Set $CURRENT_QA_RELEASE_5 to false
Re-releasing the same version (or -pl)
--------------------------------------
1. Commit the new binaries to ``phpweb/distributions/``
2. Edit ``phpweb/include/version.inc`` and change (X=major release number):
a. If only releasing for one OS, make sure you edit only those variables
b. ``$PHP_X_VERSION`` to the correct version
c. ``$PHP_X_DATE`` to the release date
d. ``$PHP_X_MD5`` array and update all the md5 sums
e. Make sure there are no outdated "notes" or edited "date" keys in the
``$RELEASES[X][$PHP_X_VERSION]["source"]`` array
3. 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.
a. Call php bin/createNewsEntry in your local phpweb checkout
b. Add the content for the news entry
4. Commit all the changes (``include/version.inc``, ``archive/archive.xml``,
``archive/entries/YYYY-MM-DD-N.xml``)
5. 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
the news entry.