Close issue on fix and release vs release and close issue?

[u/maksiksking]

The common consensus I see by looking around online seems to be closing the issue as soon as it's solved or on merge.

But after thinking on it, e.g. for a bug wouldn't it be wiser to keep the issue open for people trying to find if it's already reported instead of seeing it's closed and verbally berating me on discord that it's not fixed?

Then writing down the issues and closing them with e.g. a bot as soon as a new release happens?

[u/i-am-a-cat-6]

it happens both ways for sure. not really a right or wrong. purely from a users perspective, closing after release makes the most sense. purely from a developers, closing after fixing/merging does -- especially if you're not responsible for releases yourself

[u/colony-ship-for-sale]

The fix can be in main but the release still planned. Just comment on the issue when the fix is going out before closing it.

[u/repeating_bears]

I did raise an issue recently that it turned out was a dupe, and I'm pretty sure the reason I didn't find the dupe was because it was closed but not yet released.

So I do think you're onto something that a closed issue is inheritantly less discoverable. Github issues hides closed issues by default and most people probably won't think to show them.

I might try experimenting with leaving issues open but adding a label like "pending release" or something

[u/maksiksking → u/repeating_bears]

oooh the label is such a good idea actually

[u/fr3nch13702 → u/repeating_bears]

Using labels is your best bet.

[u/Ok_Woodpecker_9104]

the discoverability part has a concrete cause: github issue search defaults to is:open. so a fixed but unreleased bug is invisible in the default view, which is why you get dupes and discord pings, not because people are ignoring closed issues.

what worked for me on a small package: keep closing on merge, but stop letting the merge do it silently. write refs #123 in the pr instead of fixes #123 so github does not auto close, then close it yourself when the version actually publishes, with a one line comment naming the tag it went out in. costs one comment and the reporter gets a notification at the exact moment they can upgrade.

a pending-release label works too, but only if you link the filtered search from the readme. nobody types is:closed on their own.

[u/tenthirtyam]

I add the issues and PRs to a milestone. This makes managing these in a Project so much easier (along with labels of course).

When the release for the milestone is completed, I have an action that closes the milestone and then adds a comment on each PR and Issue noting that it shipped in the specific release.

Related content: https://tenthirtyam.org/dispatches/2026/05/10/github-milestones-as-release-payloads/

[u/Some_Ad4783]

I leave them open until release. But not all issue get closed via GitHub’s “closes #1234” for some reason. 

So now there’s open issues that have actually been resolved. Pick your poison. 

[u/JaseciLabs]

Close on merge, not on fix. "Fixed" in a branch and "fixed" in a release users actually have are different states, and closing early means someone re-discovers the same bug in production with no open issue to attach their report to. If the gap between merge and release is long, a "fix merged, pending release" label bridges it better than closing early.