--- /dev/null
+ 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
+
projects / php / commitdiff