Separate auto milestones for master and beta

[SaschaCowley]

Is your feature request related to a problem? Please describe.

Currently, the auto milestone script incorrectly applies the milestone of the alpha version for PRs based on beta or rc. See, for example, #17219, which was merged to beta, but had the 2025.1 milestone auto-applied, even though it was going in to the 2024.4 release.

Describe the solution you'd like

Have separate milestones for master and beta merges, and use the appropriate milestone when merging a pull request based on the base branch.

Consider extending this to rc, though this should be less necessary, as merges to rc are rare.

Describe alternatives you've considered

• Make no change, but make sure we are vigilant about correcting auto milestones.
• Only apply auto milestones to merges to master.

Additional context

Milestones are automatically applied to issues that are closed as completed. We would need to make sure the correct milestone is applied to these as well, by inspecting the PR that closes them. I am unsure if this is possible with the GitHub Actions API.

[CyrilleB79]

Yes, I have also seen that closed issues with a "Won't Fix" are auto-milestoned with the current milestone. It does not make sense to me.

Should people closing these issues (NV Access but also triagers) remove this milestones? If yes, maybe we should update the triage doc?

[SaschaCowley]

@CyrilleB79 are you talking about issues with the close/wontfix label? If that's the case, the current auto-milestone script only applies labels to issues that are closed as completed, so the solution there is to close as not planned. This could of course be improved to take in to account labels, but that's a separate discussion.

[CyrilleB79]

My bad. These were probably issues closed normally, whereas they should have been closed as not planned.

I guess that issues that are fixed externally (e.g. #17155) should also be closed as not planned?

We, triagers, should probably be more careful to this when closing issues. (cc @Adriani90 FYI)

[SaschaCowley]

I guess that issues that are fixed externally (e.g. #17155) should also be closed as not planned?

I'd say so, yes. Perhaps we should add a close/externally-fixed label for these issues as well. Thoughts, @seanbudd?

[seanbudd]

I agree with labelling as externally fixed, but I'd prefer to close them as planned. I think it's worth tracking issues as fixed if they are fixed, even if they are fixed externally. Having them get added to the release milestone isn't really an issue IMO.

[SaschaCowley]

I think it's worth tracking issues as fixed if they are fixed, even if they are fixed externally.

Hence adding a label saying they have been fixed externally. Closing as not planned makes sense here, as we don't plan to fix external issues in NVDA.

Having them get added to the release milestone isn't really an issue IMO.

It becomes an issue when using milestones as historical artefacts, or when using them to check for changes in particular releases (I would tend to use git log for this, but milestones are also a valid tool).

[seanbudd]

Closing as not planned makes sense here, as we don't plan to fix external issues in NVDA.

Closing as completed also makes sense, as the fix was made. We track external issues in this repository because sometimes its unclear if a hack/workaround in NVDA is possible, and we want to track when these external issues are fixed. I think closing as not planned makes it harder to differentiate rejected issues vs valid issues that were fixed.

It becomes an issue when using milestones as historical artefacts, or when using them to check for changes in particular releases (I would tend to use git log for this, but milestones are also a valid tool).

I find some historic value in the fix being tied to a release, I think it's worth noting things that are fixed in a certain release cycle, even if the fix wasn't done in the NVDA repository.

[SaschaCowley]

I find some historic value in the fix being tied to a release, I think it's worth noting things that are fixed in a certain release cycle, even if the fix wasn't done in the NVDA repository.

Fair enough. I just wonder how this really relates the history of the two projects? For instance, consider a fix that goes into main in another repository months before it is in a formal release of that product? It may be listed as being fixed in NVDA 20xy.z, even though the stable version of the other project with the fix isn't released until NVDA 20uv.w is out.

[seanbudd]

I guess its more of "we know it was fixed before this release came out" to me. Same value in closing older issues as fixed even in cases we don't know which release it was fixed.