Re: Proposal for release process (Was: Re: [PHP-DEV]4.1.0)

On Sun, 11 Nov 2001, Andi Gutmans wrote: >I didn't quite understand what you mean :) I didn't get it first either. :) >All I said was that if you create a branch say "4.1.0" and you want to >release "4.1.x" from that branch later on whilst HEAD has already moved a >couple of months you're going to have a hard time doing it. The idea is NOT to go on for _months_ with the HEAD. The idea is to make it shorter by keeping the amount of testing smaller. And this is what the versioning stuff was aimed at too. Most people out there think that when a version number changes on the 'micro' part (4.1.x) it means that there are only bug fixes in this release and I can safely go ahead and update without fearing that something breaks. At the moment, you can't trust on this. It's definately NOT like "all the other projects do". Zeev suggested at some point that we should drop the last number altogether. That indeed would make the current way of doing things more correct but would not really solve anything in the user end.. 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 ) 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 (group@php.net) should first ratify all this stuff. :) Oh, I forgot..rules are bad..we're all volunteers..etc. crap. Why can't we improve this? "It has worked for so long now.." and that is bull too. It might have worked and might work for a while but if we really want to make the quality better, we have to make some changes. Look at the bug database: 803 open bug reports (feature requests, doc probs and website probs excluded) of which about 70% are not bugs but user errors and such. That still leaves us with over 200 reports that are real bugs. Some of them are in extensions which have been abandoned or the people who 'maintain' them don't simply care. But this is another story. (btw. in Scripting Engine related bugs there are 69 open reports.. :) --Jani ..who's getting pretty tired at banging head on the wall..