ACCEPTED: PEP 285

[Paul Rubin]

Tim Peters <tim.one at comcast.net> writes:
> > Doesn't matter what you call it, if a 2.1 script can't run at all or as
> > expected on 2.0, that is a major change in the _colloquial_ sense.
> 
> I expect you phrased that backwards, yes?  If you use a new-in-2.1
> feature, then of course it's not going to run under 2.0.  The other
> direction is almost always tractable, although in some cases it does
> take foresight, or the active application of hindsight, to pull it off.

I don't think he phrased it backwards.  "If you use a new-in-2.1
feature" presupposes that 2.1 has features that aren't in 2.0, and I
think James is arguing that it should not.  The issue is just how
often you're willing to tell people they have to upgrade.

If I'm running 2.0, and 2.1 comes out, it's pretty similar, so I don't
upgrade.  Then someone sends me a script that using some new-in-2.1
feature and I have to upgrade.  Then 2.2 comes out with new features
of its own, someone sends me a 2.2 script and I have to upgrade again.
Next, 2.3 comes out and I want to run a script that uses bools.
Whoops, another upgrade.  It gets tedious!  I can deal that every
18-24 months (i.e. when I buy a new computer) but I don't want to do
it every 3-6 months.  Of course if I was really serious about security
I'd have to do a line by line code review of every one of those damn
releases before installing it, making it even worse.  As it is, I
mostly just shut my eyes and install, but I feel like I'm stepping off
into a vast and dangerous unknown every time I do it.

The stability-valuing approach would be DON'T PUT NEW FEATURES into
releases like 2.1 without good reason to get the particular features
out fast.  New library modules, or enhancements of existing ones, are
generally ok (I mean stuff like network protocols, not string
methods).  Bug fixes are ok.  Stuff like bools (even if you think
they're a good idea) should be added only in major releases, not minor
ones like 2.3.  Stuff like dict comprehensions should be added at the
same time as list comprehensions, or not at all; again, not in a minor
release.  If 3.0 comes out and it has a lot of cool new stuff that's
not in 2.0, that's great, I'll upgrade, but I want the new features
and upgrade pain in a single release, not drop-drop-drop like the
Chinese water torture.

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.