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 : $ cvs tag -b php_4_0_RC 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_RC 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_RC 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_ 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