[Python-Dev] Re: Stability and change

[Alex Martelli]

On Wednesday 29 May 2002 05:11 pm, Michael Gilfix wrote:
	...
> get burnt. Perhaps Python should adopt a versioning number such
> that major changes occur during odd numbers, etc.  Just so users

Yep.  I proposed this in the very first message of the thread with this
subject, about 2 months ago I believe.  Linux (and perhaps more
relevantly Ruby, a language very close to Python in many respects)
use even minor versions for the releases of the stable-track (slow,
prudent and backwards-compatible change -- in theory, at least; not
sure how good is Ruby at satisfying this promise... Linux is so-so),
odd minor versions for the releases of the experimental-track (fast,
frequently-released, not necessarily backwards compatible changes).

However, after bouncing the idea back and forth a bit, in several
variations suggested by various people, Guido ended up rejecting it.
It may be satisfactory for Ruby, but he decided that it would not be
for Python, no matter how close the two cases appear to others.
And he _is_ the BDFL, after all.

Some help on this score may hopefully come from the recently
formed Python Business Forum.  Among other tasks the PBF plans
to choose and exhaustively test certain Python releases, proposing
to Guido to designate those releases "Python in a tie" (I think GvR
came up with this specific monicker), then backporting fixes to them
&c to ensure the long period of stability typically desired by commercial
end-users (I think the target is 18-24 months vs the 6-8 months
target of Python minor releases).  I apologize if this summary is in
any way imprecise -- http://pbf.nuxeo.org/ has authoritative info.


Alex