[Python-Dev] Timing for Py2.4

Raymond Hettinger python at rcn.com
Mon Mar 29 21:18:58 EST 2004


[Anthony Baxter]
> Remember: a 2.4 that's broken is far, far, far worse
> > than a 2.4 that's 6-8 weeks later.

Py2.4 is not broken, I use it everyday for everything! It is much more
stable than any previous pre-alpha.  I'm sensing more FUD than fact.

The alpha release is not the same as final release.  So, can we
compromise and agree to get out a late May alpha but leave the final
release date as a range (allowing for your "baking" delay if it turns
out that there is some value in letting the bits sit idle for a few
months)?



[Anthony Baxter]
> > Python's release cycle has historically been cautious and measured.

Py2.2 didn't get debugged or fully documented for ages.  Py2.3 didn't
even have a feature freeze until the second beta.  This time we will.
We're already fairly conservative with two alphas and two betas.  

Besides, inaction!=caution.  Without an alpha, only a handful of us
exercise the code.  All the time buys you is bitrot and irrelevance.



[Barry]
> Why don't you cut your teeth on a few micro releases, starting with
> Python 2.3.4?  Then if you still want to do it <wink> you can be the
> release manager for Python 2.5.

The world is safer with me doing an alpha than with 2.3.4 which has to
be perfect.  Also, I have no desire to be RM, but that appears to be the
only way to avoid months of unnecessary delay.



[Guido]
> In the past, the real test for any version has been the final release
> -- the alpha and beta releases get very little exercise except by some
> diehards.  They are still necessary because *some* important folks
> take them seriously, but don't expect that a flawless alpha + beta
> means a perfect final release.

Genexps are reasonably exciting and I think a little cheerleading on the
newsgroup may help the betas exercised.  Also, the AST is different from
other new features in that just running existing apps will exercise the
compiler.



> issues with new functionality
> usually don't come to the light until months after the final release,
> when people have started writing real code using them.  That's why
> there will be a 2.4.1 release...

The implication is that sitting on the release for extra months doesn't
buy us anything except old age.



Raymond




More information about the Python-Dev mailing list