No new features (was Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Modules ossaudiodev.c, 1.35, 1.36)

[Anthony Baxter]

On Wednesday 09 March 2005 12:21, Greg Ward wrote:
> On 09 March 2005, Anthony Baxter said (privately):
> > Thanks! I really want to keep the no-new-features thing going for
> > as long as possible, pending any AoG (Acts of Guido), of course.
>
> Grumble.  How do you feel about upgrading optparse to sync with Optik
> 1.5.1?  I'm a bit embarassed that Python 2.4's optparse has __version__
> == "1.5a2" because I didn't release Optik 1.5 in time.

The version string update I don't see being a problem. 

> And yes, there were some tiny new features in 1.5 and a few more coming
> in 1.5.1:
>
>   * SF patch #870807: allow users to specify integer option arguments
>     in hexadecimal, octal, or binary with leading "0x", "0", or "0b"
>     (1.5 final).

Again, this is a new feature, and having it behave differently in 2.4.1 to
2.4 could be confusing - but I'm not absolutely against this.

>   * SF feature #1050184: add 'append_const' action (patch by
>     Andrea 'fwyzard' Bocci) (1.5 final).

New feature?

>   * Keep going if importing gettext fails (so optparse can be used
>     in the Python build process) (1.5 final).

Bug fix.

>   * Fix so the 'merge' script works again (bugs spotted, and mostly
>     fixed, by Andrea 'fwyzard' Bocci). (1.5.1)

Bug fix.

>   * SF bug #1145594: add 'finish()' method to OptionParser so
>     applications can explicitly break reference cycles, making life
>     easier for Python's garbage collector. (1.5.1)

Is this purely an internal method, or something that people would
use as part of the API? If it's an API change, it shouldn't be included.

>   * SF feature #988126: add 'epilog' attribute to OptionParser
>     (and constructor arg): paragraph of text to print after the
>     main option help. (1.5.1)

API change.

>   * Corrected French translation (po/optik/fr.po) (Laurent Laporte).
>     (1.5.1)

Bug fix.

> Every one of these is useful to someone, and none of them are even
> remotely destabilizing.  But they all add functionality that would be
> present in 2.4.1 and not in 2.4.  That doesn't bother me in the
> slightest, but I guess it bothers some people.

Initially, I was inclined to be much less anal about the no-new-features 
thing. But since doing it, I've had a quite large number of people tell me how
much they appreciate this approach -  vendors, large companies with huge
installed bases of Python, and also from people releasing software written 
in Python.  Very few people offer the counter argument as a general case -
with the obvious exception that everyone has their "just this one little
backported feature, pleeeease!" (I'm the same - there's been times where 
I've had new features I'd have loved to see in a bugfix release, just so I
could use them sooner).

> I'd like to check this in for 2.4.1.  But I won't if anyone says "don't
> do it".  Nor will I if no one else says "do it".

Well, 2.4.1rc1 is out in about 12 hours time. If you want to check in the
bugfixes before then, please feel free. If you don't want to apply bits and
pieces, then don't worry about it. I don't want anything but critical fixes
landing between 2.4.1rc1 and 2.4.1 final. Remember that 2.4.2 will turn
up inevitably, it's not like this is the last release between now and 2.5...

I should also add that the above is really just policy as it's evolved - if
people want to discuss this (am I being too strict?) I'm happy to talk 
about it. I'd even suggest a BOF at PyCon, except I won't be there :-(
 
-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.