make it more easily possible to determine which release fixes an issue when looking at the issue

[glyph]

I often find myself looking at a closed issue, and wanting to know whether that issue was fixed in any existing releases. It would be nice for towncrier, which has the full database of linked issues and is invoked to generate release notes during the release, to do something to link up those issues.

One way to do this would be to add comments to the issues with a github API key, but perhaps a properly formatted commit message that referenced the issues would allow Github's own automatic linking logic to find the commit / tag / release from the issue; I'm explicitly leaving this open-ended since I don't have strong feelings about exactly how it should work, only that it would be nice to have.

[glyph]

c.f. https://mastodon.social/@glyph/113188361514158447

[adiroiban]

Thanks for the report

but perhaps a properly formatted commit message that referenced the issues would allow Github's own automatic linking logic to find the commit

towncrier automatically removed the news fragment from git.

towncrier could also automatically trigger a commit with a message.

As long as you do not merge release PR with squash, I think that this will work and GitHub will auto-link.

[adiroiban]

What I do for my private GitHub repo / product is something like this:

• Create a milestone for each release
• Once a release is done, look at all the PRs or Issues that were closed and are not associated to a release PR, associate them with the release milestone.

With this, next time you will read the page of an issue or a PR in GitHub, you will see the associated notes

This works for both Issues and PRs and in GitHub UI, you get a nice preview in the list of

and if there is no release milestone associated, it means the fix was not yet released

---

You can use projects, instead of milestones... but projects are not visibile in the Issues/PR lists

[adiroiban]

Another option is to link all issues, to the release issue

I try to do it as a proof of concept here #659

and then, on the issue itself you get

---

but this only works for GitHub Issues.

If you fix something by using just a PR... bad luck.

For PR, there is the option to link a "development" issue

---

I did this with manual actions ... and some features are in preview ... I don't know if they are available over the API

[adiroiban]

I often find myself looking at a closed issue, and wanting to know whether that issue was fixed in any existing releases.

At work, I do this all the time as part of support request.

Using the milestone conventions works for me and it's not that much of a manual work to be done by the release manager.

I am still using milestone due to legacy work... as in the past GitHub Projets were not avaialble.

Now, you can replace milestones with Projects.
And GitHub has a nice filter to show all the closed issues or PRs that don't have milestones and just associated them with the current release milestone.

It is some manual work, but it's not that much... so I never considered automating the process... especially when there are so many other high priority task at work :(

[adiroiban]

I left some feedback and I am happy to review a PR for this.

I am happy to see more release automation in towncrier and have towncrier as the "swiss knife" tool of every release manager

[altendky]

I often find myself looking at a closed issue, and wanting to know whether that issue was fixed in any existing releases.

With a little luck (or attention to detail) the PR is linked to the issue so I scroll down the issue history, find the linked pr or commit, from there github tells you what tags it is present in.

Note the 24.8.0 and 24.8.0rc1.

But sure, I can imagine more tooling could certainly be useful. Just wanted to make sure the existing GitHub feature was clear.

[glyph]

But sure, I can imagine more tooling could certainly be useful. Just wanted to make sure the existing GitHub feature was clear.

Thanks, that is indeed a useful thing I look at sometimes. But it can be a little fiddly and annoying to navigate to, particularly if you're trying to scan through a set of a dozen or so bugs that you're tracking.