At 05:28 12/11/2001, Jani Taskinen wrote: >Zeev suggested at some point >that we should drop the last number altogether.
I *what*? Perhaps I was high on that Kossu :) I was never in favour of dropping the 3rd digit. > That indeed would >make the current way of doing things more correct but would not >really solve anything in the user end.. Indeed. >What I suggested: >Only bug fixes go into the release branch. >And all the nifty new features and big changes and BC breaking stuff >go into the next release branch (HEAD). (ie. version 4.x+1.0 ) As I've said repeatedly, there's no reason *at all* to move from our old, de-facto standard versioning scheme to this one. The process is fine, but the following version should be a .0.1 add-up. I really fail to see why you mix the version number with what a new version may include. And, of course, it has nothing to do with the fact that once we branch a release branch, be it 4.0.7 or 6.4.2.4.6.1.2.5.4, no new features should go to it - only bug fixes. >It's not very far from what we are doing right now. >We have two branches, the release one and HEAD. But what I suggested >was to keep the release branch and commit bug fixes into it and >release bug-fix-only-releases from it. > >Why would it be hard time doing it? It's not hard as long as certain >rules are followed. It needs a bit more work and people who are dedicated >for doing it. But the core developers ([EMAIL PROTECTED]) should first >ratify all this stuff. :) Jani, it's simply not going to work. New features and bug fixes are often closely interweaved. Also, *bugs* and new features are often closely interweaved. What you are suggesting is basically to step with full steam into the biggest synchronization nightmare possible. The system and rules we have right now are good. The flaw, if any, is in the amount of work that goes into bug fixing, from your point of view, which I can certainly understand. But changing the system to what you propose will not improve things - only more efforts towards bug fixing will. Not only that - it's bound to create synchronization problems from hell, things you don't even dream about when you use a simple linear development model as we do today. It has nothing to do with whether or not php-dev can live up to certain rules, or whether it should or shouldn't do so. Rules are not the problem here. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
