On Tue, 22 Jun 2021 19:49:12 -0400 Ned Deily <nad@python.org> wrote:
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.
+1. "Affected versions" and "fixed versions" at least seem necessary. This is also what exists on e.g. the Apache JIRA tracker. Regards Antoine.