[Python-Dev] 2.2.1 release mechanics

[Guido van Rossum]

> >>> Guido van Rossum wrote
> > Note that I was just in time checking in the backward compatibility
> > bool(), True and False builtins (returning ints, of course).  If
> > Anthony is listening, could I add those to 2.1.3 too?  This will ease
> > backporting 2.3 code to 2.1.3 and 2.2.1.
> 
> I can't decide on whether this should go in 2.1.3 or not. On the
> plus side, it's unlikely to break things. On the minus side, it is 
> breaking the "contract"[*] about what goes into a minor release.
> 
> [*] where "contract" is between the python developers and the people
> who install and use it. up until now, we've said 'minor releases are
> bugfixes only' - changing this at the last minute before a release
> feels a bit wrong, somehow.
> 
> Given the nature of the bug fixes in 2.1.3, I _really_ don't want to
> give people _any_ fears that they might have backwards compatability
> concerns to deal with. I can't see any way that adding bool/True/False
> to 2.1.3 will break things, but it's a perceptions thing, I guess.  I
> just want to see 2.1, 2.1.1 and 2.1.2 go away :)
> 
> Hm. At this point (well, at the point I got Guido's email), the 2.1.3
> release is pretty much done but for
> . make install on creosote.
> . rename the file in ftp.python.org (it's called rc0 right now).
> . pushing the 'hidden->active' button on sf.
> . sending the email announcement.
> If I'm going to add this, I'll need to recut the release. In any case,
> I'm not going to do this right now (it's late) - I'll look at it first
> thing tomorrow and try to decide then. I really _would_ like feedback,
> though.

I think our current discussion is pointing towards a (slight)
loosening up of the rules for micro releases, but I think that it's
better not to push this particular fix into 2.1.3 after all.  I did
push it into 2.2.1 -- we've already added enough tiny features that I
think this is acceptable.

I think I'd like to sell it as a way to ease backporting 2.3 library
modules to 2.2.x, rather than as a way for people to get used to
writing bool(x) instead of not not x, and True or False instead of 1
or 0.

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