RE: [PHP-CVS] cvs: php4 / configure.in /main php_version.h

I agree that not having enough people to do sound QA is a problem we can't version ourselves out of. But! If we have a branch in CVS that we have taken the time to QA, basing new bug-fix releases on that tested branch will require a lot less QA than starting a new branch from the main trunk, and thus it is a sensible way of doing minor releases for now. That is the point I was trying to get through. - Stig On Fri, 2002-03-15 at 11:44, Andi Gutmans wrote: > I agree with Zeev on this one. > The way to solve problems in PHP's release process is not by changing the > versioning scheme but to do real work and improve the QA process. Extra > numbers won't solve the problem of lack of QA resources! > > Andi > > At 11:28 AM 3/15/2002 +0200, Zeev Suraski wrote: > >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