[Python-Dev] "Unstable" is an ambiguous word...
Mon, 8 Apr 2002 22:23:20 +0200
On Monday 08 April 2002 22:00, Guido van Rossum wrote:
> > > 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.
> > 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:-).