we should either ditch this file, or update it to reflect the current process. (i'd almost prefer we just replace it with an entirely new document, perhaps based on derick's email[1], so we can have the document not be GPL'd, which is just silly.)
one way i'd amend the process, relating to the use of cvs tags: the current 4.2.0 (4.2.x?) branch was tagged as 'PHP_4_2_0'. this means that the actual 4.2.0 release will need to use some other tag. the way i'd like to see it done is for the branch tag to look something like BRANCH_PHP_4_2 (yes, with 'BRANCH_' in the name. it makes it drop-dead easy to tell what is a branch, and what is a release tag) with release tags of the form PHP_4_2_0_RC1, PHP_4_2_0, PHP_4_2_1_RC1, etc. (all lowercase would be fine, too, and would match most of the existing tags.) i really don't want to stir up the versioning debate again. if we're doing three-digit branches and patch-level releases, adjust the suggested tag names accordingly. i think the whole release process could be tightened up, to boot -- i don't see why there needs to be any delay between branching for the release and kicking out the first release candidate. i don't think it significantly changes the odds that the first release candidate will be the only release candidate (which are near zero, in either case), but i think that having a downloadable tarball is always going to attract more testers. jim [1] http://marc.theaimsgroup.com/?l=php-dev&m=101545438113053&w=2 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
