[Python-Dev] Re: Stability and change

[Christopher Petrilli]

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