On Jun 22, 2021, at 18:35, Irit Katriel via Python-Dev <python-dev@python.org> wrote:
On Tue, Jun 22, 2021 at 11:22 PM Terry Reedy <tjreedy@udel.edu> wrote:
With 2.x gone and a backport flow, essentially all issues are for main, so leave version tags off the issue (and eliminate the need to update them!). For enhancement requests I agree we probably don't need to keep updating the version (though it might be useful to know which version the user was looking at when coming up with the suggestion).
But I think for a bug report it's useful to know the most recent version on which the bug was reproduced. A large part of triage work is to check whether a bug report is still relevant. If you see "version 3.5" then it makes sense to check on a current version and either update the issue or close it.
I think this points out a problem with our current bug system and one that it would be good to try to resolve in migrating to a new system: that is, the ambiguity of the "version" metadata in an issue. Today, that list of versions is used in at least three different ways: 1. to document in what Python versions the issue is present; 2. to document in what Python versions the issue should be fixed, 3. to document in what versions the issue was fixed. In many, probably most, cases, the "version" field of a particular issue is used in both ways. When the issue is opened, the version is often set to the versions affected. Then at various stages in its lifecycle, the issue's version field will generally be changed to (possibly) reflect the candidate versions for potential fixes (based on current policy) and later (possibly) to the versions for which a fix was actually merged. The various sets of versions are useful information for different purposes. It would be good to try to find a way to retain both, i.e. something like "affected versions", "targeted versions", and "fixed versions". In any case, resolving the current ambiguity would be good and could also save triage and housekeeping work. -- Ned Deily nad@python.org -- []