[Python-Dev] Re: Stability and change

[Guido van Rossum]

> Again this *appears* to be arguing for what we already do.  Maybe
> with one difference: I assure people on c.l.py that PLabs will
> continue distributing I.J.K for increasing K for as long as the
> community contributes the work for bugfix releases.  Perhaps you're
> saying that PLabs should take that over?

No, this is for all active developers.

I agree that we don't have to change what we do very much, but I'm
looking for a way to "spin" it to satisfy the more conservative user
community (the ones who still like Python but are worried about the
future).

Since there are different "use cases", this may be hard or impossible,
or we may have to explain it differently for different folks.

For example, developers who distribute useful Python programs want to
have a way to ensure that code they write gets run on a compatible
Python version.  We could make it easier to have different X.Y
releases installed on the same system; this is already pretty easy on
Unix if you know about "make altinstall".  If we invent a standard way
to specify the required version (or range of versions?) then that
might be sufficient.  You shot down my #! proposal for Windows, but
maybe we can do something else.  (Obviously this only works for
programs, not for modules or packages.  Package authors pretty much
know the drill.)

Beginning programmers have a different concern: they don't know much
about software evolution, Python may be the first or second language
they learn, and they hear that there's a concern about the rate of
change.  How can they know what that means?  I've seen plenty of posts
from such people worrying that in a few years from now they might have
to learn a whole new language.  They needn't worry, but it needs to be
addressed with more explanation than "don't worry, the BDFL is
watching over you."

> > I'm not sure what exactly we need to *do* now.  Be clearer to the
> > user community that we're still maintaining 2.1.*?
> 
> Are we?  We've made no effort to backport any bugfixes into 2.1.3,
> and to the contrary declared that we wouldn't do anything with 2.1.3
> except fix the single gc-vs-trashcan disaster.  We're not even
> building a Windows installer for 2.1.3 (last I heard).  I don't
> think anyone is going to buy that as "maintaining" the 2.1.x series;
> I sure don't.

Maybe we need to use a different word?  Barry noted that 2.1.x is the
most popular "stable" release and will probably remain that.  So maybe
we should say this is the "recommended" release.  And then maybe we
need to revise the decision not to make a Windows installer.  Or maybe
we *do* need to spend more effort backporting patches (not necessarily
PLabs, but *somebody*).

Another way to keep adding value to older releases is by backporting
the build procedure enhancements.  Once we've figured out how to build
Python 2.3 on, say, some ancient version of AIX, maybe somebody should
port that back to 2.2 and 2.1.  That's not a language change, but
still improves the usability of the release.  (For some folks.  Maybe
the AIX user community is small enough that we shouldn't care, but
there are other platforms with similar issues.  I recall that you
backported the new 32 bit Windows installer to 2.1.2; maybe the recent
fixes could be backported to 2.1.3.)

OK, so I *am* proposing to do something different.  Maybe it's not
very attractive to work on old releases.  But Zope Corp does it all
the time (and the fact that Zope 2.x requires Python 2.1.x may be an
additional motivator).

> > Delay the 2.3 release and spend more time on 2.2.2 (assuming that
> > 2.2.1 is about to go out)?
> 
> 2.2 did go out the door unfinished <wink>.  But, again, we could
> have delayed it two years and it still would have been relatively
> unstable: there's just no substitute for getting thousands of users
> *using* a release.

Indeed.

> > ...  While I agree that 2.1.x is the most stable release, there's
> > also a significant user population who want to use 2.2 (e.g. the
> > new Boost library wrappers use new-style classes).  We should
> > maintain the 2.2.x line for their benefit.  And then maybe we
> > could take our time releasing 2.3 while experimenting with new
> > features to our heart's content.  To counteract the fact (as Tim
> > noted) that few users bother to download betas, maybe we could
> > release 2.3 relatively rough, clearly mark it as an experimental
> > release, and work on improvements and stability in 2.3.1, 2.3.2
> > and so on, until we're happy to call it stable and start
> > experimenting with 2.4.  While we're working the kinks out of
> > 2.3.x, the most stable release advertised would be 2.1.x, and
> > adventurous users could basically choose between 2.2.x (advanced
> > but stable) or 2.3.x (bleeding edge).
> 
> You can fiddle what you *call* what we're already doing anything you
> want, but if a long-lived two-branch comes out of this, I quit
> <wink>.

Would you settle for a separate CVS repository? :-)

> I do believe we should direct more effort into bugfix releases; that
> can't be done without taking away from something else, though
> (that's a trivial deduction: everyone is already overloaded).

Yup.  That's why we need to put some effort in communication to the
users, and some in a real change of priorities.

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