[Python-Dev] Stability and Change

Geoff Gerrietts geoff@gerrietts.net
Wed, 10 Apr 2002 19:43:10 -0700


Quoting Guido van Rossum (guido@python.org):
> Do you think it's necessary to synchronize between different
> companies?  Feel free to try, but there could be all sorts of reasons
> why you may differ.  Since you can have several different minor (but
> not micro) releases on the same system (at least Unix) it shouldn't be
> a big deal -- if you require Python 2.x, just put
> 
>     #! /usr/bin/env python2.x 
> 
> at the top of your files.

I think the advantage to maintaining a single "curmudgeon" release
over the space of 18 months or so, is that it gives extension
developers a single testing and backporting target.

That allows people who have, for one reason or another, a need to
stick to one release for some window of time > 6 months, a stable
platform that has a decent chance of being well-supported across the
board.

The presentation for this might be "this release is no more stable
than the current release, but is well-supported and will not see major
changes".


> > In summary I'd like a note from Guido on the download page 
> > saying "we do releases every 6 months but if you prefer a longer 
> > cycle, go for 2.1.3 for now, and I will designate a stable 2.4.X 
> > release some time in 2003".  It doesn't mean 2.2 or 2.3 is bad
> > in any way, but it gives us a decent planning horizon.
> 
> Do I really have to spell it out?
> 
> Also, I don't want to *recommend* any particular release.  I'd like to
> just say "pick any release you're comfortable with, and stick with it
> as long as you like."

In some ways I think that Guido is the /wrong/ person to say this. So
would Tim or pretty much anyone else who is identified as a "core
developer". The Curmudgeon's Release may enjoy a certain amount of
support from the core community, but it should be an external
artifact.

The rationale here is that the python community should continue to
adopt new features, and the development of the language should not
halt, and no particular release should be "blessed" as the One True
Release Until The Next True Release. The Curmudgeon's Release /should/
be an alternative -- but it would be good if the alternative were
somewhat standard, because that would increase the likelihood of
widespread support.

All that needs to happen is some community who can do it, needs to
emerge to do it. My C skills are acceptable, but my experience in
compilers and interpreters is minimal and my time sapped on many
fronts. I joined the list because I thought I could help with this
effort, and I will, but I hesitate to accept responsibility more than
a bite-sized piece at a time.

> > Maybe EuroPython is the time to pick this up.
> 
> I'll be there!

I won't, so please post the results of any discussion :)

-- 
Geoff Gerrietts        <geoff at gerrietts dot net>
"Ordinarily he was insane, but he had lucid moments 
when he was merely stupid."        --Heinrich Heine