[Python-Dev] "Unstable" is an ambiguous word...

[Guido van Rossum]

[me]
> > And there's the crux -- that one is still EXPERIMENTAL while the book
> > is being written.

[Alex]
> 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
2.2.2 releasemeister.

I also like Andrew's idea of making everybody commit their changes in
both branches -- to scale the effort of keeping the maintenance branch
up-to-date.

--Guido van Rossum (home page: http://www.python.org/~guido/)