Re: RFC:PHP Release Cycle

I have little experience with merging CVS branches - however, any time that you have a system combining information solely based on differences in the data, there is a decent possibility for the information to get mangled in the process. While there is still ample possibility for errors to occur when the developers have to commit to two branches instead of one - I believe that these types of error are much easier to track (by reviewing commit logs) and correct. Errors induced by automated processes are likely to be harder to detect and correct (who wants to roll back x versions and manually combine two trees.) Just my 0.02 cents. I am very glad that you are discussing some method to make the RC code stable for the testers! :) --zak At 12:38 AM 11/10/00 +0200, Andi Gutmans wrote:

I have done some work with CVS branches and I don't find them that evil. It actually worked quite well for me. I am not quite sure we would have problems to create a release branch, apply the patch there and merge it into the main branch. I am not convinced that it's better for the person to make two separate patches. Andi At 08:41 AM 11/9/00 -0800, Rasmus Lerdorf wrote:

Merging branches with CVS is quite evil and if we start down that path I predict some significant CVS messups. A branch that is never merged is not nearly as bad and I could perhaps go for that. I also thinks it makes more sense. When we tag a release and create a branch for it then that is the branch towards that specific release. Other development can go on in the main branch. If something needs to be changed for the release it gets changed on the branch *AND* it gets changed in the main branch. Slightly more work for the developer in that he has to check it into 2 branches, but I don't mind that extra bit of work. The number of changes during release testing should be absolutely minimal and the fact that there is some headache involved in making a change during the release cycle is probably even a good thing. Sometimes we may find that there are just too many broken things and we abandon the release branch and watch for the next opportunity to try another branch from the main branch. So if you think of it visually we will have a main trunk with a bunch of short dead-end branches with some of these branches ending up as releases. -Rasmus On Thu, 9 Nov 2000, Phil Driscoll wrote:

I think that the most important element in what James and Zak have said is to do with no new code getting added to the RC between test and release - only big fixes. I know that there has been some reasonably heated

discussion

about this in the recent past. I suspect that the best compromise is to branch and merge CVS, then those who want to develop new stuff can

continue,

and those who want to bug fix can do that. Whatever else we do, I can

see no

way of assuring quality if new code keeps going into the RC while it is being tested. As to the time taken, I suspect that 1 week between RC announcement and tested release is Ok. Even if, as Richard says, that is a long time by

open

source standards, so what! I'm sure that the bulk of PHP users would be happier with stable product a few days later - the odds are that they

would

have had to spend the extra days fixing and patching anyway. If one ouput from the build tracker is a table plotting the test

status with

platforms/servers against php core plus the various extensions and this table is made visible via a link from the downloads page, then those downloading the new version can get a good idea of what they are buying into - and even contibute to the table if they wish. Cheers -- Phil Driscoll Dial Solutions +44 (0)113 294 5112 http://www.dialsolutions.com http://www.dtonline.org -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net

-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net

--- Andi Gutmans <andi@zend.com> http://www.zend.com/