[Python-Dev] "Unstable" is an ambiguous word...
Guido van Rossum
Mon, 08 Apr 2002 23:14:06 -0400
> > And there's the crux -- that one is still EXPERIMENTAL while the book
> > is being written.
> That depends on how often the experimental branch is fed back into a
> new stable one. If every 6 months, well, sure. But I think it
> would not need to be anywhere as frequent.
Neil suggests 18-36 months. Maybe we should put off 2.3 until, oh,
late 2003? And plan to shove a whole lot more new features into it?
And maybe move some minor features into the 2.2.x branch? (I hardly
dare suggest bools. :-)
> > So which distinction should we make? In a previous msg you disliked
> > STABLE vs. CURRENT. Would you prefer STABLE vs. EXPERIMENTAL or
> > CURRENT vs. EXPERIMENTAL?
> I think both sound very good in the abstract (while stable vs current
> does not). It seems to me that stable vs experimental is slightly
> preferable because it appears to draw a neater distinction, and
> some connection of 'current' to other-than-stable might otherwise
> attach from (e.g.) the BSD terminology. But there might be some
> other consideration that doesn't come to my mind right now that
> makes current/experimental preferable.
OK, STABLE vs. EXPERIMENTAL it is.
> There may not be ONE way out -- but maybe TWO tracks would do,
> instead. On the stable track, releases that could break previously
> correct code would be highly infrequent; on the experimental ones,
> releases would be frequent -- ideally frequent enough that people
> wouldn't go to CVS unless they're interested in contributing to the
> internals, but could feel they're "on top of the leading-edge
> RELEASE" (aka the experimental-track release).
This also sounds similar to what Neil proposes.
So maybe we're closing in to consensus: significantly slower "major"
releases (like 2.3), more effort in "bugfix" releases (like 2.2.1) and
more of those. And guess what, Anthony Baxter has offered to be the
I also like Andrew's idea of making everybody commit their changes in
both branches -- to scale the effort of keeping the maintenance branch
--Guido van Rossum (home page: http://www.python.org/~guido/)