Read my proposal for versioning rules before replying.. You can find it in the mailing list archives.
--Jani On Sat, 10 Nov 2001, Mike Rogers wrote: >Because that appears to be rediculous idea. At present, unless you have a >problem which requires you to upgrade, you stick with the stable proven >release. The only reason why Linux kernel gets released so often is because >it contains security fixes that affect everyone and are in the public. >Security fixes should be released immediately. Just bug fixes, added >features and optimized functions should only be done in major releases. > Keep in mind, with every new feature, we break another two. Do you >_really_ want that many new things on production machines that haven't been >properly testes. In 4.0.7, there was a complete rework of the Zend memory >management by my understanding- Imagine not testing that at all and putting >it out. You are asking for serious problems. > Administrators do not want to be upgrading on a weekly basis (or less). >We need to keep stable, quality, secure releases- and that only comes from >extensive testing. > > My point- yes it is more work, but let's make a new release candidate >from 4.0.7 and release it. It's stable and seems very reliable. It also >makes less work for Zend releasing thier optimizer for each release of PHP. > > Please guys- do not consider regular small releases. Major releases >that are properly tested and released (and yes I do keep up on CVS much of >the time to test and contribute to the code- I am one of those properly >testing it) > >-- >-- >Mike > > > >----- Original Message ----- >From: "Jani Taskinen" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Cc: <[EMAIL PROTECTED]> >Sent: Saturday, November 10, 2001 4:34 PM >Subject: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV] 4.1.0) > > >> On Sat, 10 Nov 2001, Zeev Suraski wrote: >> >> >Guys, >> > >> >We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on >> >which 4.1.0 is currently scheduled to be based on, has branched away a >few >> >months ago. Some people have expressed concern that releasing 4.1.0 >based >> >on that branch is not a good idea, because there have been so many >changes >> >in the HEAD branch, and synchronizing fixes and so on is going to be a >> >headache. >> >> I have a bad feeling about this branch and I vote for dropping it and >> starting new from HEAD. There are several reasons for this: >> >> The change between 4.0.7 -> 4.1.0 (and also sudden change of the >> release master from Zeev to Stig) has confused some people according the >> discussion on php-qa list a while ago. Many of them might have tested >> 4.0.7 RCs but not necessarily all have tested the 4.1.0 RCs. >> Not to forget the 11th of September.. >> >> I have no idea who have tested the latest RC. Does anyone have? >> After the latest RC there have been a LOT of fixes in the release >> branch and also several fixes in the HEAD (which weren't MFH'd) >> and there hasn't been any new RCs after those fixes were committed. >> >> How many people test the branch (from CVS) ? >> Has anyone kept any list of the test results and problems found ? >> Has anyone kept eye on fixes done which weren't merged to the branch ? >> >> Answer is: We don't KNOW. >> >> The thing is that the project has grown to be so big that we can not >> afford long periods of time between releases. Too much stuff gets >> in without testing. Too many NEW bugs are introduced and like it has been >> said many times before, not enough people really pay attention to fixing >> them. Developers simply ignore them and continue adding new stuff thus >> creating new possible bugs. >> >> Anyone think what I think? "Release early, release often" >> >> >http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/x147.h >tml >> >> This works very well for Linux, why wouldn't it work for PHP ? >> Our QA team is very small. It has actually gotten smaller during the >> last 6 months instead of getting bigger like it should have. >> >> Enough ranting, let's get into fixing this situation. I can't see any >> solutions that won't bite us but one solution that won't bite as so >> badly in the _long_run_, as if we delay it or release too early we're >> gonna get hurt. My proposal is this: >> >> - Release the current branch as 4.1.0 but clearly state that there >> will be 4.2.0 soon. Also start the 4.2.0 branch from HEAD now and >> the QA process on it with some things kept in mind: >> >> o Any serious problems found (by our best QA team: the real users) in >4.1 >> we fix them in 4.2 and announce that after 4.2 release we start >> following the versioning rules for real. >> >> o We continue releasing 4.2.x versions out of the 4.2 branch but with >> ONLY bug fixes in it. And we do this OFTEN. Any new stuff goes to >HEAD. >> We should decide what amount of fixes or with what severity triggers >> the (short) QA process for the 4.2.x branch. >> >> o After there have been, let's say 5 big ones in HEAD, we start new >> branch, 4.3 and QA process moves there. The QA should not take so long >> with this. Security related fixes should trigger new release process >> immediately. >> >> o Any changes into extensions from now on should include the start of >> using the version numbers in extension. Also, if there are changes in >> many extensions or there are big changes in some extension we make >> another 4.2.x release. (compromise for Zeev's sake :) >> >> o Any big changes or changes that might possibly break things should >> be announced on the php-qa list and only after QA has tested that the >> changes don't break anything, they should be allowed into CVS. >> >> - We need to have ONE place where to keep the RC packages. And we >> need to have also Windows build of the RCs at this same place. >> Having the packages in someone's home directory is not very good idea. >> Better place would be at http://qa.php.net/ >> >> - We name persons for each branch who work together with QA team and >> make sure the releases are tested properly. ie. This person merges all >> fixes into the branch and keeps record how the testing goes on and >> decides when is the time to release. >> >> o List of succesful builds on different platforms >> - Create a build tracker to qa.php.net (Bat[e] ?) >> >> - Make the bug system to send bug reports to php-qa list >> and only confirmed reports to php-dev thus making it easier >> for developers to notice which reports are real bugs. >> Huge amount of the reports coming in are bogus. >> >> With all this I think we can avoid this kind of situations in the future >> as the amount of testing will get smaller. And democracy doesn't always >> work. :) >> >> Of course these release-dictators should be elected somehow so that >> evil dictators never get the power again. :) >> >> --Jani >> >> >> -- >> 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] >> >> > -- 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]
