[Python-Dev] Bugfix releases should not change APIs (original) (raw)

Tres Seaver tseaver at palladion.com
Sat May 29 02:31:05 CEST 2010

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Terry Reedy wrote:

I had the strong impression that there was a policy that x.y.z bugfix releases should only fix bugs and not add new features and revise current ones. The rationale, as I understood it, is that x.y.z releases should be increasingly better implementations of a stable x.y feature set. Adding features is 'bad' because code using a new feature will not work in previous releases of the same x.y version. Changing features is even worse because it may also break working code going forward.

Because of this policy, an x.y.z Windows installer (I do not know about others) deletes any earlier release of the same version. Also, there is no What's New in Python x.y.z (relative to x.y.(z-1) since such should be empty. Consequently, violations of the policy are pretty much silent and well hidden. Yesterday, I spent two hours puzzling over the failure of my previously 'green' test sequence that tested a custom test function. I finally realized that the change was not due to anything I did (or undid), but a change in 3.1.2 in the interaction of StringIO.truncate, StringIO.getvalue, and print(x, StringIO()). (I should note the it is the usual stability and quality of Python that made me slow to blame Python rather than myself.) 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 I have fixed my tests so they works in 3.1.2 and should work in other 3.1 releases, but that would be a nuisance to test. Of course, I should not have to worry about API changes within a version series. I think issue 8840 illustrates another reason for the bugfix-only policy. New x.y features and docs are (nearly always) added before the first beta. They can then be tested, discussed, and improved. This 'cooking' does not occur for bugfix releases. For reasons I give in my response on the tracker, I think the new behavior is buggy and the doc deficient. 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.

+1 on #1 as the general policy.

I don't have enough skin in the game of the 3.1.x world to have an opinion about this specific breakage, but I have certainly seen other examples in the 2.x releases, where such a resolution was the appropriate outcome.

Tres. - --

Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwAYEkACgkQ+gerLs4ltQ6AuQCfTk4mAl3ClpE1uu6nBRNrNjBc g54AoI2SObUNn/d0RvIbYj/vl7HDQbbj =U8z2 -----END PGP SIGNATURE-----

More information about the Python-Dev mailing list