Justtechjobs.com Find a programming school near you






Online Campus Both


php-developer-list | 2000111

Re: [PHP-DEV] Re: [PHP-QA] RFC:PHP Release Cycle From: Andi Gutmans (andi <email protected>)
Date: 11/09/00

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 <email protected>
> > For additional commands, e-mail: php-dev-help <email protected>
> > To contact the list administrators, e-mail: php-list-admin <email protected>
> >
> >
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
>For additional commands, e-mail: php-dev-help <email protected>
>To contact the list administrators, e-mail: php-list-admin <email protected> 

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

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