Re: Release process (was: Re: [PHP-CVS] cvs: php4 / configure.in /main php_version.h)

On Fri, 15 Mar 2002, Edin Kadribasic wrote: > I agree that the main issue here the release process. I don't think it's > working very well now. How long ago was PHP_4_0_7 branch made? It's not that > ecouraging fixing a bug or adding a new feature and telling people that the > fix or feature will be released in 6 months or so. > > So how do we cut the time from branch to release down to 2-4 weeks? sounds ok to me, i'll mail a faster release schedule later this day and if nobody objects i'll package rc1 tomorrow. Derick > > Edin > > > ----- Original Message ----- > From: "Zeev Suraski" <zeev@zend.com> > To: "Stig S. Bakken" <ssb@fast.no> > Cc: "James Cox" <james@wherewithal.com>; "Jani Taskinen" > <sniper@iki.fi>; > <php-cvs@lists.php.net> > Sent: Friday, March 15, 2002 10:28 AM > Subject: RE: [PHP-CVS] cvs: php4 / configure.in /main php_version.h > > > > At 11:09 15/03/2002, Stig S. Bakken wrote: > > >The new versioning scheme is a good idea at the right time. You should > > >give better arguments than "the old scheme has (always worked|worked > > >before)". > > > > And I did (inability to sync multiple trees, lengthy release cycles (from > > branching to release), userbase perception of what version numbers mean in > > the OS world, time from introduction of new features, or infrastructure > > improvements and their delivery to the userbase, legitimizing patch > > releases by "making them look better" (there's no excuse for a QA messup, > > no matter if you call it 4.2.1., 4.2.0pl1 or 5.0.456), and I think there > > were more). I have no motivation to go into them all over again, and the > > fact the old scheme worked seemed like a pretty good KISS summary. > > > > In reality, if we don't have enough QA resources (and we don't, ask Derick > > who has to wait for 3 weeks from branching to RC1 (!)), then picking on > the > > versioning scheme is looking for the coin under the light, when it already > > slipped through the cracks to the sewers. Fix what requires fixing, not > > the things that are and always have worked. Right now, it appears we're > > getting the bad of both worlds - we lost the dynamic nature of an OS > > project (fast turnaround time), but we also don't have commercial grade > > QA. To the QA people - we appreciate your work, however, there's simply > > not enough of you. It's not your fault, of course. > > > > If we want to do it right, we need to get a strong QA infrastructure, > which > > would allow us to go from branch to release in 2-4 weeks (and then this > > whole version numbering business loses its point). Solving the problem by > > legitimizing pl's as 3rd digit releases is perhaps self-convincing, but it > > doesn't change anything, except for breaking consistency with out > > versioning scheme. > > > > Zeev > > > > > > -- > > PHP CVS Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, visit: http://www.php.net/unsub.php > ----------------------------------------------------------------------- PHP: Scripting the Web - derick@php.net All your branches are belong to me! SRM: Site Resource Manager - www.vl-srm.net -----------------------------------------------------------------------