[Python-Dev] Re: Stability and change
Mon, 8 Apr 2002 12:58:47 -0700
Quoting Guido van Rossum (email@example.com):
> I very muich doubt that the corporate users who are currently worried
> about the fast pace of change are interested in any particular
> feature, and I don't think that any backported feature is going to
> make that previous version more popular amongst managers with decision
> power. The question in front of them is, "should we use Python or
> not", not "should we use Python 2.1". To answer that question, they
> want to perceive "Python" as stable, not "Python 2.1".
I think, as this discussion slowly seems to be winding down and my
list subscription goes through, that I can finally contribute
One of the points I've seen brought across is that "stable python"
needs to be more widely acclaimed as such. The example seems to be the
2.1.3 release, or the 2.1.* series in general. I agree with this,
The remains of the discussion seems to circle around how to number or
manage the changes so that it's easier to know how things are
developing. To this, I think that picking a scheme is a lot less
important than documenting what that scheme means to the people who
are using it. Maybe we can cash in on some of the ideas put forward by
other people, maybe we can't, maybe we shouldn't. What's important is
not how we do it, but that we're explicit about what we do.
The remains of this note are going to be long-winded, so if you're
prone to start skimming, now would be a good time <wink>.
BACKGROUND (where I'm coming from)
A little background -- I'm part of a company (at my other email
address) that views Python as part of their competitive advantage.
We engage in weekly rolls into production, with product cycles that
last between two and four weeks. Three of us write python regularly;
four of us write DTML and HTML. Management duties, release
scheduling, release management, deployment, and site maintenance
responsibilities are scattered liberally among this crew of seven.
We do a lot of business at this site, which makes those scattered
responsibilities fairly time-consuming for some of us.
Despite this, we manage to maintain the aggressive schedule, which
has in turn enabled us to bring in big partnerships and close
substantial deals with a very small core of engineers holding it all
In many ways, we are the sort of story that serves as an
advertisement for Python (though you should stop well short of
holding up our code as examples, if you know what I mean).
On the other hand, a full overhaul of the site to advance to a new
version of Python is a substantial project. Between the dependencies
on third-party products, the extensive customizations we've had to
make, the QA overhead that goes into a full site regression, and the
management overhead that goes into tracking down all the bits and
pieces -- that's about a month-long project, though we might be able
to fit it into 3 weeks.
This puts us into the "conservative" camp. For some time now, we
have regarded it easier to steer around, work around, or hack around
bugs in 1.5.2 than to upgrade. We've backported a fix or two. It's
still not enough. Recently, we've agreed to upgrade, and managed to
secure executive permission to take a 3 week cycle (scattered over
the next couple months) to do the updating work.
My situation may be atypical, but I think that we're the sort of
operation that the python community doesn't really want to alienate.
THOUGHTS ON STABILITY
When I use python for myself, I prefer to use 2.2, because I prefer
to stay current. When I develop python for a wider audience, I plan
for 1.5.2, because that's what I'm pretty sure I can count on people
to have available. I can speculate why this is so, but it would be
When I looked at upgrading to the 2.* series of python interpreters,
I wasn't sure where to target. 2.0 is for all intents and purposes a
dead end. 2.1 is seeing some active bugfix development, but there's
no visible commitment from the community to continue that trend. In
fact, when the topic gets broached, it more often than not gets shot
down with "not likely, who would want to waste their time on doing
that?" or some variation therof. 2.2 appears stable, but there's a
bugfix release in the works that hasn't (as far as I know) been made
official yet. In other words, none of the 2.* series appeared like
particularly attractive targets to shoot at, because all of them
appeared to be unsuitable for the needs of our organization. I
decided to shoot for 2.2, because it's hard to tell when we'll be
able to do the upgrade again, and I wanted to solve as many problems
as could be solved, now. It appears that may have been a bad choice,
given progress with 2.1.3.
People talk about a 6 month gap between releases, but I'm not sure
anyone recognizes that timeframe as "average" yet. You can have an
average with only two measurements, but it really takes three to
make a series, and the gap between 1.5.2 and 2.0 was considerably
longer than 6 months. The point here is that when you adopt any
given minor version of python, you have no idea how long you have
before you're obsolescent. Six months is reasonable, if that is in
fact what we continue to hit. But being predictable is more
important to "the conservative crowd" than any particular interval
In conclusion, I think that what "the conservatives" are looking for
is really quite easy to provide. I summarize them as:
- Be predictable. If we're putting off pain until 3.0, make a guess
when we're going to need to deal with that pain, so we can start
preparing. If 3.0 is 9 months off, that's a lot scarier and more
concerning than if it's 2 years off.
- Be explicit about the process. If the process is to stick a fork in
the ham and call it "stable" just before moving on to the next minor
release, then be explicit about that process.
- Be explicit about obsolescence. If things in 2.3 or 3.0 or X.Y are
shaping up to be so different that bugfixes won't be back-portable,
then identify that fact early -- and make an effort to provide a
reasonable target for people to upgrade to, as soon as possible.
The perceived problem with change being too rapid may be just that, a
perceived problem. With adequate and careful communication, the
problem may disappear entirely. It may not, but we can always dream.
Anyway, that's about all I can contribute, after thinking long and
seriously about what I feel like our company needs, and trying to
ignore the specific details of implementation. I hope it's helpful.
Geoff Gerrietts <geoff at gerrietts dot net> http://www.gerrietts.net/
"Politics, as a practice, whatever its professions, has always been the
systematic organization of hatreds." --Henry Adams