[Python-Dev] Re: Stability and change (original) (raw)

Aahz aahz@pythoncraft.com
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

major.minor.bugfix

we do

major.minor.enhanced.bugfix

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

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 year later.

Aahz (aahz@pythoncraft.com) <*> 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