[Python-Dev] Bugfix releases should not change APIs

[Nick Coghlan]

On 29/05/10 09:03, Terry Reedy wrote:
> After filing
> http://bugs.python.org/issue8840
> I was rather shocked to be told that the code-breaking and
> policy-violating change was intentional because being 'more consistent
> with other file-handling APIs out there' was somehow more important than
> consistency within version releases. It also seems to me that discussion
> of code-breaking API changes like this should involve more than one user
> and one developer. See
> http://bugs.python.org/issue6939

As Benjamin noted, that change was discussed on python-dev and actually 
made at Guido's direction.

> So, I think
> 1) the supposed bugfix-only policy should really be the policy;
> 2) the violation in 3.1.2 should be reverted in 3.1.3, and the API
> change reviewed in the normal 3.2 alpha/beta process.
> I am curious as to what others think on both points.

The bugfix-only policy remains in place, but there are corner cases 
(such as this one) where the definition of what is and isn't a bug gets 
fuzzy and we need to make a judgment call as to whether to fix them or 
not. In particular, fixing bugs often runs the risk of breaking existing 
workarounds for those bugs.

The decimal module, for example, has a standing policy to treat 
deviations from the standard as bugs, and this may lead to changes in 
the module if the standard is updated between two releases.

This specific change was discussed on python-dev and the chance of 
breaking existing 3.1 code was deemed preferable to retaining semantics 
that were seen as broken, so I would be against reverting it.

However, it may be worth modifying the policy to ensure that such 
exceptional bug fixes be mentioned prominently in the release notes and 
on the download page for that maintenance release.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------