[Python-Dev] Re: Stability and change
Sat, 6 Apr 2002 15:29:25 -0500
On Sat, Apr 06, 2002, Guido van Rossum wrote:
> Personally, I hate the way Linux releases are numbered (I can never
> tell which one is stable and which one isn't). But I could get used
> to it if we used the micro version number to indicate stability -- in
> particular, 2.2 would be experimental, and 2.2.1 and following would
> be stable; 2.3 would be experimental, and 2.3.1 stable.
I'm kind of in agreement with Tim; I don't think this buys much. Seems
more important to me to specify process than stability per se.
> It would, however, require a big change in how we present new releases
> to the world. Currently, Once 2.x is out, anything running 2.(x-1) is
> labeled obsolete, or at least oldfashioned. That needs to change!
> The website needs to present at least two options:
> - Bleeding edge (e.g. 2.3 alpha, or 2.3 once it's out)
> - Stable (e.g. 2.2.1)
> There may be more options: Zope 2 currently requires 2.1.2 and will
> require 2.1.3 as soon as it's out; other people still swear by 1.5.2.
> (I don't think that the 1.6 and 2.0 lines are still popular.)
What I suggest is that instead of
This way, only major.minor releases can introduce actual language
changes, but enhancement releases can pick up library changes. If this
sounds at all workable, I recommend issuing a quick BDFL pronouncement
changing 2.2.1 to 126.96.36.199.
Then what we might try for a 2.2.1 release is making the new boolean
type a module that people can start using.
I am also a bit amused because an early draft of PEP 6 did try to
address this issue, but you and Tim dissuaded me. I think both of you
were right back then, but it's still kind of funny to see it picked up a
Aahz (firstname.lastname@example.org) <*> http://www.pythoncraft.com/
"There are times when effort is important and necessary, but this should
not be taken as any kind of moral imperative." --jdecker