ACCEPTED: PEP 285

[Alex Martelli]

Paul Rubin wrote:
        ...
> The stability-valuing approach would be DON'T PUT NEW FEATURES into
> releases like 2.1 without good reason to get the particular features
        ...
> The proposal of having separate "development" and "stable" release
> tracks like Linux has sounds like a promising direction for keeping
> both camps (language development enthusiasts and would-be production
> users) happier than they are in the current situation.

Not really, because "new features" *DO* get into Linux "stable" releases,
as long as they don't break anything in terms of backwards compatibility.
(That's the theory -- defects in execution often mean that the "stable"
releases aren't all that stable, but that's another issue).

And that is exactly what you and Mr. Logajan seem dead set against -- and
it's utterly different from the concern which I was trying to address with 
my dual-track proposal (now being discussed in python-dev).  That concern
being the reluctance of some substantial software development shops to 
choose a platform for which the only choices are [a] feature-frozen, 
nothing-new, bugfix-only releases or [b] a frequent stream of releases that 
break previously-correct code.  [b] is perceived as bad because of the
need to rework existing stable code developed in said shop (or purchased
from third parties).  [a] is perceived as bad because, as Eric Raymond so
well puts it in his "Magic Cauldron" essay, the perceived value of software
lies in very good part, not in its bits, but in the expected future stream 
of maintenance, enhancements and fixes.  A "frozen" release, in which no
new feature will ever go, lowers expectations on that score too drastically
to let the managers of those shops feel good about it.

Your concerns on the other hand seem all tied to what OTHER people
may be doing out there.  You WANT case [a] software -- but you're
dead set against OTHER people getting to choose [b], because they
may then use [b], the bleeding-edge experimental version, to write some
neat script that you'd like to run (but can't while staying stuck at [a]).

I don't think that any reasonable variation on my proposal will satisfy
your concern -- even assuming there IS a large constituency for "not
letting OTHERS have new features [so they won't write software that
uses them -- so you won't receive that software and need upgrades]".
I'm not sure it's all that large and substantial a constituency.  And even
if it were, I don't see how to meet that concern without driving away
an important group of neophile/hackers to more welcoming languages
(or a fork): the "experimental" branch of releases, if existing at all, 
would still produce the scripts you don't want others to write -- if it
did not exist, neophiles would go elsewhere.


Alex