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]
