[Python-Dev] Re: Bug fix releases

[Guido van Rossum]

[Aahz]
> >> 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.

[Guido]
> >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
> >backwards compatible.

[Aahz]
> 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.

Then I respectfully disagree.  We took plenty of time to discuss
"print >>" amongst ourselves.  I don't see the point of letting the
whole community argue about every little new idea before we include it
in a release.  We want good technical feedback, of course.  But if it
takes time to get emotionally used to an idea, you can use your own
time.

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

We will surely put in an effort, but we're limited in what we can do,
so I'm inviting the community to pitch in.  Even just a wish-list of
fixes that are present in 2.1 that should be merged back into 2.0.1
would help!

> My one central point is that I think this will fail if PythonLabs
> doesn't agree to formally certify each release.

Of course we will do that -- I already said so.  And not just for
2.0.1 -- for all bugfix releases, as long as they make sense.

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

I hope that the experience with 2.1 will validate most bugfixes that
go into 2.0.1.

> The main reason I suggested two betas was to "lockstep" the bugfix
> release to the next version's feature release.

Unclear what you want there.  Why tie the two together?  How?

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

But the Windows change is clearly a feature, so that can't be added to
2.0.1.  We'll have to discuss this particular one.  If 2.0 doesn't
work on MacOS X now, why couldn't MacOS X users install 2.1?  They
can't have working code that breaks, can they?

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