Bug fix releases
aahz at panix.com
Sat Mar 3 22:55:28 CET 2001
In article <mailman.983646726.27322.python-list at python.org>,
Guido van Rossum <guido at digicool.com> wrote:
>> I think so, yes, on that latter clause. I think perhaps it wasn't clear
>> at the time, but I believe that much of the yelling over "print >>" was
>> less over the specific design but because it came so close to the
>> release of 2.0 that there wasn't *time* to sit down and talk things
>> over rationally.
>In my eyes the issues are somewhat different: "print >>" couldn't
>possibly break existing code; nested scopes clearly do, and that's why
>we decided to use the __future__ statement.
>But I understand that you're saying that the community has grown so
>conservative that it can't stand new features even if they *are* fully
Then you understand incorrectly. There's a reason why I emphasized
"*time*" up above. It takes time to grok a new feature, time to think
about whether and how we should argue in favor or against it, time to
write comprehensible and useful arguments. In hindsight, I think you
probably did make the right design decision on "print >>", no matter how
ugly I think it looks. But I still think you made absolutely the wrong
decision to include it in 2.0.
>So that relegates us at PythonLabs to a number of things: coding new
>modules (boring), or trying to improve performance of the virtual
>machine (equally boring, and difficult to boot), or fixing bugs (did I
>mention boring? :-).
>So what can we do for fun? (Besides redesigning Zope, which is lots
>of fun, but runs into the same issues.)
Write new versions of Python. You've come up with a specific protocol
in a later post that I think I approve of; I was trying to suggest a
balance between lots of grunt work maintenance and what I see as
perpetual language instability in the absence of any bug fix releases.
>Your math at first confused the hell out of me, but I see what you
>mean. You want us to spend time on 2.0.1 which should be a bugfix
>release for 2.0, while at the same time working on 2.1 which is a new
Yup. The idea is that because it's always an N and N-1 pair, the base
code is the same for both and applying patches to both should be
(relatively speaking) a small amount of extra work. Most of the work
lies in deciding *which* patches should go into N-1.
>Guess what -- I am secretly (together with the PSU) planning a 2.0.1
>release. I'm waiting however for obtaining the ownership rights to
>the 2.0 release, so we can fix the GPL incompatibility issue in the
>license at the same time. (See the 1.6.1 release.) I promise that
>2.0.1, unlike 1.6.1, will contain more than a token set of real
>bugfixes. Hey, we already have a branch in the CVS tree for 2.0.1
>development! (Tagged "release20-maint".)
Yay! (Sorry, I'm not much of a CVS person; the one time I tried using
it, I couldn't even figure out where to download the software. Call me
>We could use some checkins on that branch though.
>> This means that each feature-based release gets one-and-only-one pure
>> bugfix release. I think this will do much to promote the idea of Python
>> as a stable platform for application development.
>Anything we can do to please those republicans! :-)
>> There are a number of ways I can see this working, including setting up
>> a separate project at SourceForge (e.g. pythonpatch.sourceforge.net).
>> But I don't think this will work at all unless the PythonLabs team is at
>> least willing to "bless" the bugfix release. Uncle Timmy has been known
>> to make snarky comments about forever maintaining 1.5.2; I think this is
>> a usable compromise that will take relatively little effort to keep
>> going once it's set up.
>With the CVS branch it's *trivial* to keep it going. We should have
>learned from the Tcl folks, they've had 8.NpM releases for a while.
I'm suggesting having one official PythonLabs-created bug fix release as
being a small incremental effort over the work in the feature release.
But if you want it to be an entirely community-driven effort, I can't
argue with that.
My one central point is that I think this will fail if PythonLabs
doesn't agree to formally certify each release.
>> I think one key advantage of this approach is that a lot more people
>> will be willing to try out a beta of a strict bugfix release, so the
>> release N bugfixes will get more testing than they otherwise would.
>Wait a minute! Now you're making it too complicated. Betas of bugfix
>releases? That seems to defeat the purpose. What kind of
>beta-testing does a pure bugfix release need? Presumably each
>individual bugfix applied has already been tested before it is checked
"The difference between theory and practice is that in theory, there is
no difference, but in practice, there is."
I've seen too many cases where a bugfix introduced new bugs somewhere
else. Even if "tested", there might be a border case where an
unexpected result shows up. Finally, there's the issue of system
testing, making sure the entire package of bugfixes works correctly.
The main reason I suggested two betas was to "lockstep" the bugfix
release to the next version's feature release.
>Or are you thinking of adding small new features to a "bugfix"
>release? That ought to be a no-no according to your own philosophy!
That's correct. One problem, though, is that sometimes it's a little
difficult to agree on whether a particular piece of code is a feature or
a bugfix. For example, the recent work to resolve case-sensitive
imports could be argued either way -- and if we want Python 2.0 to run
on OS X, we'd better decide that it's a bugfix. ;-)
>> If there's interest in this idea, I'll write it up as a formal PEP.
Okay, I'll do it after the conference. I've e-mailed Barry to ask for a
--- Aahz (Copyright 2001 by aahz at pobox.com)
Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6
Nostalgia just ain't what it used to be
More information about the Python-list