Stability and change

[Alex Martelli]

<posted & mailed>

James Logajan wrote:

> Alex Martelli <aleax at aleax.it> wrote:
>> 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.
> 
> This proposal seems to have good promise and if well executed would
> probably mollify a curmudgeon such as myself.

I do not think so, considering all of your recent remarks.  I'm trying
to point this out because [a] I may be misunderstanding the remarks and
I'd like to be put right in that case and [b] there is a risk of such a
scheme being considered as a magic bullet and causing disappointment
when it turns out it's not.

You had a script written on a given release, 1.5.2, which also needed
to work with completely different major releases, such as 2.0.  The
scheme I'd like to see would not ensure that a change of major release
number breaks no existing code: that would be too constraining, "lock
in" any existing implementation bug -- not the Python I dream of.

Further: I've repeatedly seen you complaining, quite apart from stuff
written for 1.5.2 not working identically in 2.0, about a very
different issue: that (e.g) 2.1 would let one use NEW things that
2.0 didn't have.  Again, as long as the new things don't break
previously correct code, I don't envisage the dual-tracking idea
as removing such occurrences.  As I see things, along the stable
track a minor release would try to ensure *backwards* compatibility,
but NOT freeze features, much less bug-fixes.

Linux's scheme surely has execution problems too (it IS a HUGE base
of code and a LOT of contributors after all), but even excluding
that, and judging by intention, you should see it does not meet your
objections (I don't know what WOULD meet them).  The idea is that a
program which runs correctly on (e.g.) 2.4.20 will keep running on
2.4.21 (no similar guarantee going from 2.5.20 to 2.5.21, i.e., on
the experimental track), but it's *FINE* if a program is written
that neets "2.4.21 or more" and DOESN'T run on 2.4.20 because of
some bug that was only fixed, or some small feature that was only
added, in 2.4.21.  As I read your remarks, this would not be
satisfactory to you.


Alex