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

[Alex Martelli]

On Tuesday 09 April 2002 05:14, Guido van Rossum wrote:
	...
> > 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?

I think 18-36 months is a very reasonable rate for releases on
the stable branch.  I also think there should be an experimental
branch that lets the "whole lot more new features" see the light
of day and get some USE -- this would let you, as a language
designer, experiment a bit, try things out, etc; lets the neophiles
(and there ARE many!) play with the new toys; and accompanied
with a guideline that a new language change doesn't get into a
new stable-branch baseline unless it's seen some commensurate
use in the experimental (say 2-3 months for minor things, more
for bigger things) it would help everybody feel better about those
changes that do make it into the new stable-branch baseline.

Selfishly speaking -- I love new toys as much as the next man;
it's just that a quarter century of experience has taught me to be
wary of said toys in code that I, or some other poor soul, may
then have to maintain forevermore.  I think this is a common
thing in people of our generation: selected to some extent for
neo-phily (we did choose computer science when it was, yes,
established, but nowhere as pervasive at today), but passed
through the refiner's fire of decades of industry fashions and
silver bullets:-).  I'd just love horsing around with the bleeding
edge experimental branch, helping shake bugs out and what
not, AND at the same time rely on relative longevity for stuff I
push out to customers.  Many would no doubt be happy with the
stable branches, a few would only go for the bleeding-edge
stuff (can't see the Twisted guys as stooping to "stable", for
example!-), but some of us would like a foot in both camps.

> And maybe move some minor features into the 2.2.x branch?  (I hardly
> dare suggest bools. :-)

What Raymond called optimizing and instrumenting, sure.  Or if there
was a way to let super be called with only self as an argument and
figure out what class's method it's being called from (not that I know
of a good one, but, YOU are the design genius around here...:-).

A class of minor language changes which I think would be OK, if
tried out in the experimental branch first, to put in the stable one:
some language construct that used to be syntactically invalid or
raise an exception and becomes valid and meaningful.  There is
some risk if try/except was used expecting the error, but in many
cases I think it's a very small risk.  That is different from a "silent
change" of language where constructs are valid both before and
after the change but behave differently, as in "print 2>1".  Or at
least so it seems to me.  And PEP 246, but I still owe you one more
rephrasing of what exactly it _means_ first:-).


> OK, STABLE vs. EXPERIMENTAL it is.

<applause> yea! </applause>

> > 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 think the "experimental track" is missing from this picture.  The
resulting arrangement will still be a significant improvement for
most people, but I think some (including my inner child yearning
for new toys to play with AND _your_ inner child yearning for
creative freedom:-) might be still happier if the experimental side
was also there.  But I may be missing something (74 more msgs
to catch up with...).

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

This reference to "both branches" does suggest there's an experimental
one somewhere, thus leading to what I see as the best overall
arrangement (and yes, dual commits seem feasible in many cases --
except for commits that need to go to experimental only, I guess).
I'll catch up now...


Alex