forked from php/php-src
/
RELEASE_PROCESS
186 lines (140 loc) · 6.48 KB
/
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
Advisory on the PHP Release Cycle
Copyright & Liciencing
This Document is (c) Copyright 2000,2001 by The PHP Group
This Document is distributed under the terms of the GNU General
Public License as published by the Free Software Foundation;
either version 2 of the License, or (at your option) any later
version.
Table of Contents
1. Introduction
2. Dealing with bugs
2.1 As a QA Team Member
2.2 As a Developer
3. Releaseing another RC
4. CVS During the Release Process
4.1 Useful CVS Commands
5 The Final Release
6 Summary
1. Introduction
This cycle should take place over roughly 10 days. When it is
decided it is time for an Release to occur Andi/Zeev (Or
Whoever) will tarball RC1, Tag & Branch CVS (see section 4)
and then announce the RC on PHP-QA and PHP-DEV. At this
point the build tracker and QA Bug System come into play.
If you successfully build PHP then report it in the build
tracker, If you then run and complete all the tests you
should report this too in the build tracker when
these features become avalible.
2. Dealing with Bugs
2.1 As a QA Team member
If you find a bug in an RC that you think is a showstopper
then, even if it is a known bug, you should report it in the
QA Bug system. This marks the bug for discussion at least,
and preferably fixing before the actual release. This system
is separate from the main bugs system so that important bugs
dont get lost in the midst if lots of feature/change request
in the approach to a release. It is imperitive where
appropraite that as a QA'er a test script, Configure options
and PHP.ini files are provided to enable the developer to
reproduce the bug, this is an important part of our job. If
you have a serious bug then you should also create a test
script to be added to the tests dir of the php source so
that at the end of the process to enable us to make sure bug
does not return. It is not difficult to create these test
scripts and a readme on it can be found in
php4/tests/README.
2.2 As a Developer
What should happen is that when a bug is reported it
is send to php-dev and php-qa as with other bugs. We should
have far stricter assignment system in this bug cycle rather
than just leaving them. Once again bugs should be able to be
marked as To Be Fixed Before release or moved to other bug
system. (This is currently the Release Masters responsibility)
Then before the actual release the qa bugs system can be
checked and if there are outstanding To Be Fixed Before
release bugs the Developers can see this easyly rather than
show stoppers being dismissed and not worried about.
When a bug is fixed the QAer who reported the bug is emailed
and asked to test again and see if the bug is fixed.
3 Releasing another RC
If it is felt necessary that a 2nd RC is needed then it
should be packaged as before and announced to both lists
again. The testing process then starts again, the RC2 is
added to the build tracker and QA'ers are asked to build and
retest the scripts as appropriate, espectially if you
reported a bug, you should test thourghly for your
bug and make sure it no longer occurs. This will normally
add anouther 3 days to the cycle, giving QA'ers time to
build test and report back, then for developers to
fix any problems.
4 CVS during the release process
At the point where the first RC is create a branch is
formed. This branch is not altered form that point onward
other than major bug fixes. Minor non important bug
fixes should not be applied to this branch but to the main
tree instead. Any major bug fixes should be applied to both
trees. The developer should test and check the RC tree then
also test and check the MAIN tree. This is their
responsibility to make sure (as far as possible) that the
bug fix works on both trees.
4.1 Useful CVS Commands
To create a Branch <Should only be done by person tarballing
the RC (The Release Master)>:
$ cvs tag -b php_4_0_<Version>RC<NUMBER>
IE:
$ cvs tag -b php_4_0_1RC1
This should be executed in the PHP directory of an up to
date checkout. Remember to also tag the Zend and TSRM repositories.
You can retrieve a branch in one of two ways: by checking it
out fresh from the repository, or by switching an existing
working copy over to the branch, I would suggest you
checkout a new copy.
To check out a new copy:
$ cvs checkout -r php_4_0_<Version>RC<NUMBER> php4
IE:
$ cvs checkout -r php_4_0_1RC1 php4
To switch a working copy (Not recomended due to possible
commiting to wrong branch)
$ cvs update -r php_4_0_<Version>RC<NUMBER> php4
IE:
$ cvs update -r php_4_0_1RC1 php4
This should be done in the PHP4 directory itself.
To revert back to normal branch you should use the
following:
$ cvs update -A
To Commit to the branch you follow exactly the same
procedure as normal
$ cvs commit file.c
MAKE SURE YOU DO NOT COMMIT TO THE WRONG BRANCH.
5 The Final Release
When it is time to make the final release the following
proceedure should be followed. The person who is tarballing
the final release should check the QA bugs system and make
sure there are no showstoppers left unfixed. If there are
then bug the person the bug is assigned to until they fix
it. If there are no more qa bugs then they should tag the
branch as php_4_0_<Version> and tarball as usual. An email
should be sent to PHP-GEN, PHP_DEV and PHP-QA about the new
release and it should be added to php.net. The windows
binaries and servelets should be built as soon as possible
and added too, as should the windows installer.
6 Summary
Here is a summary of what a release cycle might look like:
Thurs: RC is agreed on and packaged, an email is sent to
PHP_QA and PHP-DEV, the CVS is Branched and the
Release Cycle Begins.
Mon: After a weekends testing most show stoppers should
have been found (Hopefully) and the developers get to
work on fixing them.
Thurs: A second RC is released if needed with the new bug
fixes in and the QAers test again.
Sun: A review is made of all outstanding bugs and any show
stoppers should be fixed. if there are no show
stoppers then the final release is packaged and
released on the monday morning on php.net
Mon: Release is made.
James
--
James Moore
PHP QA Team
jmoore@php.net