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 188.8.131.52.
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