[Python-Dev] Re: Stability and change (original) (raw)

Guido van Rossum guido@python.org
Mon, 08 Apr 2002 12:07:44 -0400

1) Those people who want to be on the bleeding edge do not, by nature, care what release numbers mean. They'll work out of CVS repositories, or the similar "snapshot" systems, and can not be convinced otherwise.

In Python's case, that's a vanishingly small fraction of the total user base. Even the alpha/beta releases are downloaded by a disappointingly small number of people. Many Python users apparently consider themselves early adopters when they install 2.2 final when it comes out.

2) Those people who care about stability do not, by nature, update frequently, and in fact are often put off by frequent releases. To them, the more frequent the release, the more indicative it is of bad coding, or instability.

Unfortunately, what's frequent for one person appears at glacial speed for another. Since 2.0 came out, we've new Python releases (counting only the minor version numbers) every 6-8 months. Apparently the conservative forces in the community find this too often.

We can not, while maintaining our collective sanity, please both sets of people. Traditionally, Python has appealed to the 2nd set because of its very deliberative nature in the process of adding new features. The PEP process has only further rationalized what was unofficial before, and I applaud its structured approach to progress. This appeals to a large group of people who want a stable, deliberate progression of releases.

And yet, there is clamoring in the newsgroup that Python changes too fast, that we add features to minor releases that should deserve a major release, and that a minor release every 6 months is too often. So apparently we're not doing enough for these people.

I guess that it means that Python is becoming more popular -- as your audience grows, it necessarily becomes more conservative (there just aren't enough early adopters in the world).

For example, the FreeBSD/OpenBSD projects both use a very similar approach in that they have major/minor releases, with the following conventions in their numbering scheme:

X.Y.Z for the following... X = Major release, with allowed substantial backward incompatibility Y = Feature release, minimal backward incompatibility, with everything done to avoid these issues. Z = Bug fixes only. These may break people who have "worked around" the issue, but shouldn't affect 99.999% of the population.

That's what I've always thought the Python version numbering meant too. The argument appears to be mostly in the definition of "minimal backward incompatibility". I though that PEP 285 did everything humanly possible to make the bool type backward compatible. But according to the c.l.py crowd it's not enough.

The first tenant to releases is that you can not please everyone all of the time, most especially people who pay nothing for what they receive. We can make every reasonable effort to avoid backward incompatibility, but forward progress necessitates the incompatibility at some point.

Try telling Logajan or Rubin that. :-(

The key to avoiding the pain is to introduce it in stages, that one might propose follows the timeline, with the current release X.Y:

1) Propose change, formalize specification 2) Approve change after review and inclusion of feedback 3) Publish change in a prominent location

We do all that.

4) Next release X.(Y+1) provides support, but in the future mode, and only warns for existing incompatible usage.

It depends on the nature of the feature if that's possible. A new type doesn't stay confined to modules that use the future statement; whenever an instance of it is returned, there's a possibility that the receiver of that instance is not prepared to handle it. I can't make str(True) return something different based on whether the caller has executed a future statement -- it just wouldn't do the right thing in too many cases.

5) Follow on release X.(Y+2..n) provides for the new state as the default, but allows for the inclusion of old behavior via past. 6) Next release (X+1).Y drops all support for the previous syntax/cap. and forces the user to change.

Right on.

This will allow people who want to migrate to future release without upgrading huge code bases to continue to do so.

I sure hope so, but in practice, even the smallest incompatibility between 2.Y and 2.(Y+1) seems to trip people up.

One might even envision a site configuration option that would allow users to set the default behavior, but then what of those who assume differently?

Have multiple versions installed, with binaries named "python2.1, python2.2, python2.3" and "python" linked to the most popular one. Bleeding edge users can place a symlink to python2.3 in their personal bin directory if they don't want to type "python2.3" all the time.

I will point out that it is trivial to maintain multiple X.Y releases on the same machine, and for example, I have 1.5.2, 2.1 and 2.2 on my main development machine currently, and simply always make sure to specify the Python release in the #! header at the top of the file. This way in the future, I can still use it.

Apparently few people know how to use this properly. Also, there are those who want the impossible: they want no old code to break, yet they want to be able to use bleeding edge packages.

A panacea of universal happiness is a wonderful thing, but I think we need to step back and answer the question of who we are trying to please with these proposed changes, whether that group is in fact using Python at any large level, or would use Python at any large level, and whether or not we would alienate people who have been with the community for a large period of time.

This certainly seems closer to resolution that peace in the Middle East. :-)

As someone commented (and I can't remember who now), this needs to be taken in the context of increasing the spread of Python, rather than pleasing a potentially vocal minority. If such a change is advantageous to the spread of Python and its adoption, then I'm 100% for it.

Unfortunately, the vocal minority is claiming that Python's fast-paced releases are what keeps the spread from going up. Are they right? Who knows?

But if it simply cow-tows to "peer pressure," then it seems to me that it forsakes progress on the alter of change. Please remember that change and progress are not synonyms.

All in all, I don't think your post has told me anything new.

--Guido van Rossum (home page: http://www.python.org/~guido/)