php-src/RELEASE_PROCESS

	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