Hello folks,
I promised to send a more detailed mail for the upcoming release process.
Please note that this is my view on it :)
Timeline
--------
06-02-2002 Branch to PHP_4_2_0
Only fixed / patches approved by the RM maybe merged from HEAD
into the release branch. This is to make sure no stray changes
in code end up into the branch, which are not correctly tested
during the RC process.
After the branch point the QA should make a list of what should
be tested with more care than normally would have been done.
I'll call them 'special' area's from now. Things like the
fileuploading stuff should be mentioned here. Also some more
tests should be developed/written here. The set of things that
follow from this pinpointing operation are the final
requirements for this release. When they are solid here, they
should not change during the RC process to make sure there is
some point we can actually release, and not end up with RC81 or
something. Furthermore I think that one person (or two), the
Test Master(s) should be responsible to write down and maintain
the the final list.
20-02-2002 Release Candidate 1
Ok, time to test the balls out of the RC. During the RC1 period
the Critical bugs should be tested, fixed and exterminated. All
bugs that are found during this RC1 and that belong to the
critical category should be fixed before RC2. All bugs that are
found in the HEAD branch and get fixed should be merged into
the release branch by the RM. This RC should be tested by QA
and PHP-DEV.
03-03-2002 Release Candidate 2
After RC2 is release only severe and/or critical bugs that are
found in the HEAD branch should be merged by the Release
Master. The main task of RC2 is to test all bugs that are fixed
during RC1 and of course more of the 'special areas'. Testing
and the collection and ordening of results should be done by
PHP-QA.
12-03-2002 Release Candidate 3 / Final RC
In the most ideal situation all bugs that
should-be-fixed-before-release are found and fixed now. This
final RC should be tested by QA and match the requirements set
during the period between branch and RC1.
19-03-2002 Prepare release package
If no critical bugs are found we can make the release package
for the release. If any critical bugs are found, we do a new RC
every week. The reason to keep this short is that we actually
want a release some day.
22-03-2002 Release of PHP 4.2.0
Work is done, time to release.
Classification of bug severities
--------------------------------
Normal bugs: Well, all little icky things that are not totally ok.
Severe bugs: Bugs that deal with major malfunctions in extensions
Critical bugs: Bugs that deal with malfuctions in mainstream (either
minor or major). Mainstream modules are IMO: session,
mysql, gd, odbc, mssql, curl, domxml, imap, ldap, mcrypt,
oci8, pcre, pdf, pgsql, standard :), xml and xslt
Security related bugs in every extension
Crash bugs in the mainstream extensions, or crash bugs
that tend to happen a lot in non-mainstream extensions (ie
if enabling an extension crashes PHP).
Release Master: Derick Rethans
Release Bitch: Jani Taskinen
Test Master: Position vacant
Derick Rethans
---------------------------------------------------------------------
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Site Resource Manager - www.vl-srm.net
---------------------------------------------------------------------
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
