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

[Alex Martelli]

On Monday 08 April 2002 22:00, Guido van Rossum wrote:
> [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.

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.


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


> I note that for things like FreeBSD or Debian (or Linux, for that
> matter) the issues are fundamentally different than for Python.  It's

Yes -- different scale, more fragmentation, etc.


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

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).  No, that would NOT satisfy those who insist on 2.(N+1) not
running any code that 2.N didn't -- or worse, any code that 1.5.2 didn't.
I don't think there is ANY way to satisfy this request, except burying 
"Python" and giving a new name to the language (Monty?-).  We can't satisfy 
EVERYbody, I think.  But I hope we won't take this as an excuse to do
nothing at all:-).


Alex