When a PR is attached to an older milestone on backporting, we lose the milestone information because GH only allows to have one milestone per issue.
I have no idea if when the new milestone is set, we get a demilestoned event first (which would be unfortunate as it would make it harder to track the previous milestone for context).
Also from there, we could maybe add a label per branch/a label per version.
Another option could be to NOT affect the milestone when backporting but instead adding a label that would be used when generating the release notes for the release (in conjunction to the milestone).
The number of labels if we use a label per version might become a problem. But maybe we could clean up labels from time to time for old versions (except for the LTS branches).
@maxandersen also mentioned that using projects could be another option to track the versions as you can affect a given PR to multiple projects. The project UI and API might not be as handy though.
When a PR is attached to an older milestone on backporting, we lose the milestone information because GH only allows to have one milestone per issue.
I have no idea if when the new milestone is set, we get a demilestoned event first (which would be unfortunate as it would make it harder to track the previous milestone for context).
Also from there, we could maybe add a label per branch/a label per version.
Another option could be to NOT affect the milestone when backporting but instead adding a label that would be used when generating the release notes for the release (in conjunction to the milestone).
The number of labels if we use a label per version might become a problem. But maybe we could clean up labels from time to time for old versions (except for the LTS branches).
@maxandersen also mentioned that using projects could be another option to track the versions as you can affect a given PR to multiple projects. The project UI and API might not be as handy though.