Use tags on closed GitHub issues to communicate which supported and/or future stable versions are still affected.
Under the release trains models it will take a usual (i.e. not backported) bugfix 2–3 months to reach a stable release. Closing the corresponding GitHub issue once the fix hits the nightlies can set incorrect expectations about its availability and makes it difficult to keep track of known problems in stable releases.
When an issue is found to be fixed in nightly and closed, tag it with the version numbers of the current stable and beta releases, signifying that despite it being closed it still is a known issue in these supported releases and the general availability of the fix is only expected in the subsequent release. If it’s fixed in beta, tag with the current stable release version only.
For instance, suppose that the release, beta and dev channels are at 1.2, 1.3, and 1.4 respectively. If a bug is fixed and its issue is closed today, this bug still is present in the current 1.2 release and absent a backport will be present in the 1.3 release. Therefore the issue is tagged with
A library author looking at the issue will realize that they can’t reasonably assume the presence of the fix until Rust 1.4 is released. Additionally, anyone targeting e.g. Rust 1.3 can filter by the tag and see which bugs they still need to work around despite those issues being closed.
- It’s not fun to tag closed issues and easy to miss some.
- Increased tags clutter?
- Make this policy optional and apply to footguns and issues with big impact.
- Tag the issue with the branch it’s fixed on (e.g.
- Same as above but don’t close the issue until that branch becomes a stable release.
- Constant vigilance!
Can/should this be automated?