Stability and change

[Alex Martelli]

<posted & mailed>

Guido van Rossum wrote:
        ...
> About the change rate in general: it's hard to find the proper pace.
        ...
> for faster change.  I have to pick a middle ground (and it's easier to

Linus Thorvalds seems to have done pretty well with picking TWO middle 
grounds -- two parallel tracks for Linux, "stable" and "experimental".

Without the former he'd have lost the commercial interests, and "normal
people" who DO need SOME level of stability; without the latter, a crucial 
hard-core of neophile hackers might have gone away in search of other, more 
dynamic projects.  With both tracks, things seems to have been smoother.

Why don't we start thinking of a similarly dual-tracked Python -- one
track aiming at stability (in a "middle ground" sensible sense: strong
commitment to not breaking old code -- introducing small new features
and new library modules _is_ OK, else one can use a bugfix-only-"track"
for some previous release), one aiming at frequent releases, innovation,
etc.  You'd have to BDFL both tracks, I think (or else the "stable" one
would be perceived as "ugly stepsister", or, less likely, the experimental
one as an irrelevant fork should your attention be all on the stable)
and no doubt it would take experimentation and attention to decide on
such issues as average release rates, etc -- we can't just blindly
copy Linux's model, I just suggest stealing the dual-track idea.

The experimental track would give you lots of freedom (no guarantee
that what runs in e.g. 3.1.6 will keep running in 3.1.7), while the
stable one would prove reassuring to firms who are thinking of large
Python investments but quite reasonably wary of investing in a
technology they can't perceive as even _aiming_ to offer a stable
yet actively developed option.  Maybe when you release 3.0 (to pick
a nice round number) you could release 3.1 at the same time (just
about the same, perhaps) and decree 3.0.* the stable track until
further notice, 3.1.* the experimental one -- or, pick whatever
numbering scheme you prefer.


Alex