-----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 tsea...@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----- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
