Add ability to mark an issue as affecting multiple versions and close them separately
It would be useful to note when issues affect multiple versions of MuseScore, even if you mark the issue as closed for every version other than the one under current development (currently 3.0-dev).
Example use cases:
- A minor bug that only exists in the 2.0.x series could be listed as 2.0.3: won't fix, 2.0.4-dev: (active), and 3.0-dev: unaffected
- Port back a small usability change from 3.0-dev to the next 2.0.x release. List 2.0.3 as won't fix, 2.0.4-dev as active, and 3.0-dev as fixed.
- Point out an issue that was fixed in a point release but not in 3.0 development.
This way, a single issue can be used to track fixes in a couple versions at once and it's clear what all versions are affected and which ones are going to be fixed.
Comments
It's true that bugs can only be marked fixed against one version, but this is not as big a limitation as you might think. Pull requests always go into the master branch (currently 3.0) and only afterwards do they get considered for being backported into the 2.0.x branch. There is one developer (lasconic) who merges basically all pull requests. Whenever he merges a pull request into the master branch he immediately considers it for the 2.0.x branch and merges it if he things it is appropriate (basically, if it doesn't break compatibility in either direction it will go into the 2.0.x branch, if compatibility is broken it doesn't go in).
In other words, if you see an issue is fixed for 3.0, either:
You can see if which is true by reading the git messages posted on the commit page. If there is no message for 2.0.x it's because it would cause compatibility problems so it will never be fixed for 2.0.x.
Thanks for letting me know. I'll mark this as won't fix, since there's already a working system for this and I presume implementing this change would be high-effort (forum discussion about the possibility of adding a field for estimated difficulty here: https://musescore.org/en/node/111506). I suppose I was still thinking in terms of my old job—where we had to maintain patches for several versions of our software at once and tracking which changes were or were not in different versions was a pretty common part of filing bugs there—rather than git commit logs.