Terry J. Reedy <tjre...@udel.edu> added the comment:
Ari, I know that you viewed this as a behavior (bugfix) issue from the start (message 1). I changed to enhancement (feature request) in message 2 because, as you acknowledged in message 3, it is an edge case. The problem is classification can be fuzzy, while the action of merge or not is binary. I prefer enhancement as the initial classification for edge cases because (except for 2.7-only issues) we first need to decide whether a change belongs in master branch before deciding to backport. Edge cases sometimes make for messy disposition. If this is viewed as a bugfix, it can (but not 'must') be backported, first to 3.7, second to 3.6, and only third to 2.7. 2.7 is *mainly* but not exclusively still being maintained for security and build issues, with bugfixes at the discretion and judgment of the merge committer. I personally would only backport to 3.7.0, maybe but likely not to 3.6.6, and definitely not to 2.7, as I would see it as not helping 2.7 users and likely not 3.6 users. If this is viewed as an enhancement, then it should at least have, as Serhiy noted, a version-changed notice in the doc. Since Fred merged this without such a notice, but did not backport, he effectively treated this as a master-branch only bugfix. We sometime do this, such as with some exception messages. It would be fine with me to close it as such. Or we could backport this to 3.7.0rc1 (but not 3.7.1) and call this a x.y.0-only bugfix. Either way, I see the reason as being the same as for not backporting exception message changes to maintenance releases: the bugfix is not worth introducing dependence on a particular maintenance release. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33274> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
