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

[Guido van Rossum]

[Guido]
> > I'm not sure the stable track would differ in practice from what we're
> > already doing with 2.1.3 and 2.2.1.

[Alex]
> I think the clear separation would help.  Consider a book author: what
> release is he or she going to focus on?  He or she clearly wants to
> target the release that is CURRENT when the book comes out

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

> -- but need not target a release that is tagged as EXPERIMENTAL,
> unless perhaps in an advanced book.  That is how the book market
> works: there's much less demand for a book about a release of
> software that is not current any more -- or about a release that is
> experimental.

> Thus the clear message "this is current, stable, actively maintained",
> even by itself, is going to attract some more volunteer active
> maintenance -- not quite a self-fulfilling prophecy, but... it does not
> need to follow that the experimental release gets less -- if the pie
> grows, both slices may get larger.  Besides, "experimental" has its
> own allure -- you could call it "leading-edge" internally:-).

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 note that for things like FreeBSD or Debian (or Linux, for that
matter) the issues are fundamentally different than for Python.  It's
a matter of scale, really: an OS consists of many, many packages with
independant developers, and packages (more likely, specific versions
of packages) get "promoted" to the "stable" stream through some kind
of "vetting" process.  While this might resemble how some of Python's
largest packages (email, XML) are being developed, for the majority of
code in Python, both library and core, this is not how it works at
all!

Experimental stuff occasionally lives in a branch (when it's really
big) but more commonly simply begins life as a patch on SF, which is
reviewed a few times and then committed; if there's a problem, we try
to fix it ASAP.  Python is still small enough that a committed bug
(something that breaks the unittests) is relatively rare, and cause of
great turmoil!

We see two kinds of changes to Python: small things, typically
bugfixes (often a few lines in one module) that are "obviously"
correct (except when they aren't :-); and large things, typically new
features, and occasionally refactorings, which touch many files.
We're being very careful with the latter not to commit them unless the
unittests succeed (adding unittests for new features as necessary).

Should we do more?  I know the Zope developers (theoretically :-) use
branches for all new code (whether feature or refactoring, even for
the larger bugfixes), and this seems to be similar to what the FreeBSD
STABLE/CURRENT distinction is getting at.  But IMO it doesn't work all
that well for Zope (merging branches is a pain and we often see bugs
introduced by merges) and in general I'm wary of branches that require
frequent merging.

Maybe there's no way out: as long as the development of the language
goes at the pace it goes, there's not much we can do to prevent
language users to see frequent releases and frequent (small) changes.
If we reduce stable releases to once a year, that's still too frequent
for some (Rubin has requested 2-3 years between releases) while others
will be so eager to use new features that they'll risk using the
CVS head -- and then end up hating it for its instability (because all
they want is the "big" new features, not the day-to-day churn).

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