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

Christopher Petrilli petrilli@amber.org
Mon, 08 Apr 2002 11:05:53 -0400

Maybe I'm getting old, having grown up under BSD4.2, but I've continually found the Linux approach to be mind-boggling confusing, and approaching some hacker's fantasy environment. While this is great for a fast moving kernel that tries to be everything to everyone, I find it difficult to keep track of the interdependencies of patches and releases, and it's just simply not obvious to me that because something an odd number that it should necessarily be of lower quality than something of an even number.

I don't believe that the alpha-beta-gamma-candidate-release process has developed out of thin air at hundreds of organizations, and it certainly has a familiarity that to me brings with it a more serious organization. What troubles me about these discussions is the following, based on what I've run into in working with customers who have lots of Linux boxes.

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.

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.

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. 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.

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. 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
4) Next release X.(Y+1) provides support, but in the __future__ mode,
   and only warns for existing incompatible usage.
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.

This will allow people who want to migrate to future release without upgrading huge code bases to continue to do so. 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? 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.

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.

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. 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.

Chris

| Christopher Petrilli