>> It's rather a matter of agreeing when moving forward: IMO, mere style >> changes, code cleanup etc shouldn't be applied to the bug fix branches, >> as their only purpose is to provide bug fixes for existing users. > > The omission of the deletion from the 5/5 revision was a bug in that > revision. If the removal of OS9 support was documented (announced), > which I presume it was, then one could consider any visible trace > remaining to be a bug.
Well, the question is: can anything break due to the code removal. In principle, stuff *could* break even by a function that is supposedly unused, and had supposedly been removed. The problem is that a supposedly-unused function actually might be used somewhere, in some context unrelated to its intended usage. > Perhaps the policy on code cleanup should be a bit more liberal for 2.7 > *because* it will be maintained for several years and *because* there is > no newer 2.x branch to apply changes to. You mean, it's ok to break stuff with no gain in 2.7 bug fix releases? > If I were going to maintain 2.7 > for several years, I would want to have the benefit of gradual > improvements that make maintainance easier. I question whether cleanup on a maintenance branch makes maintenance easier. For example, one may (and I often do) compare the code base of the previous bug fix release with the upcoming one, to see whether any suspicious change accidentally was backported. Code cleanup is in the way of such analysis, making maintenance more difficult. Regards, Martin _______________________________________________ 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
