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