At 05:28 AM 11/12/2001 +0200, Jani Taskinen wrote: >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.
We can try and do this. I'm not quite sure it'll work in real life but I think it's it's worth a try. I agree that it is not much different than today but it requires someone who will take the job of screaming at ppl if they commit a bug fix to HEAD and not to the release branch. Also at some point we have to decide not to release bug fixes anymore for a certain version but I'm quite sure it'll come naturally with the release of the next "more major" version. >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. :) > >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. All I meant by "it has worked for so long" is that it's not as if the situation has been horrible. It's been pretty decent but I am all for improvement. IMO opinion we need to appoint a couple of people so that when there is a concensus to branch and start the release process they will make sure it is pushed a bit. >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.. :) Anything interesting? :) >--Jani ..who's getting pretty tired at banging head on the wall.. I think we're actually getting somewhere. Andi -- 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]
