How to organize (auto-closed) issues solved on master branch but not in a release yet?


  • The repository has a master branch for code contributions / pull-request.
  • The issues section is also used by “normal” users (e.g. for questions / or to see yet unresolved bugs (e.g. partially with workarounds)).


  • Closing an issue for the master branch (e.g. from a commit), also closes the issue in the issues section, even though there’s no release with that commit yet, so people will get confused sooner or later, since it’s marked as closed.

How would or already do you go about organizing this / or solving this in another way?

Things we already tried:

In the past we had a special upcoming branch, where I pushed changes to, so after a new version was released, I would only then merge it to master, thus auto-closing the issues.

The problem with that is, that coders usually want to make pull-requests onto the master branch.

Suggestion (Maybe not doable with reasonable effort?):

Ideally I wouldn’t want issues auto-closed until the commit is merged into latest release (not pre-release).

Hello @dtugend!

Thank you for sharing your use case!

Some developers have taken the approach of creating a release from an older commit, although, that approach does not address the sight of a closed issue for your users.  Aside from using a separate repository just to collect issues from the external users, some have taken to editing the commit message to avoid automatic closure of the mentioned issue.

Our community members may have more suggestions and creative approaches to share on this. 

In the meantime, I have also taken your suggestion and passed it along to the appropriate teams!  I don’t have an ETA on when or if this request will be implemented but this is in good hands.


For the Atom editor, we have a fairly complex release process that I’ve documented previously. The tl;dr is there are three main branches:

  • master where all new changes go
  • A beta branch, created from master when a new beta version is created
  • A stable branch, created from the beta branch when a new stable version is created

We close issues as soon as they are fixed on master. If people ask when it will make it to the stable release, we tell them the version number associated with master and say that it is scheduled to be available in that release (example).

Yes, there is some overhead to this. But we’ve found that it balances out the problems of:

  1. Keeping the development process streamlined for the maintainers and contributors
  2. Making the triage process easy for the maintainers
  3. New GitHub users can be taught how to figure out the information for themselves (in other words, if the current stable version is v1.23.0 and the beta is v1.24.0-beta0, then something that was merged recently is going to be available when v1.25.0 reaches stable)

And since Atom now has nightly releases, we can always tell them if it is really important they have the bug fix right away, they can volunteer to test new releases (that might have other bugs in them) by installing the nightly version. Most of them opt to wait 😀

I hope that helps!

1 Like

Thank you both for your replies and ideas!

I’ll probably try to assign the closed issues in master branch to a milestone called “upcoming” and when there’s a new release merging from master branch, I will rename the milestone to that release tag and then close it, so people can see if it’s already released and in which version or at least being pointed at that information. It’s a bit more work, but I guess it will work.

How does editing a commit message prevent auto-close of a linked issue?

I would prefer there be an additional “Resolved” state instead of just Open/Closed, so the issues that have been fixed but not released can be easily seen as Resolved and then all the Resolved issues can be automatically moved to the Closed state after the linked milestone is closed.

Up to now, we’ve just been keeping issues Open until the fix has been shipped, but then some of those issues get closed via linked PRs.

EDIT: Another option would be to add several detailed resolution categories like does, like “Fixed-  Pending Release”, “Won’t Fix”, “Closed - Duplicate”, “Closed - Fixed”, “Closed - Lower Priority”, “Closed - Not a Bug”, “Under Investigation”. We sort of do that via our “Fixed Pending Release” label, but our issues have like 5 labels sometimes and it would be better if the “resolution” was separated out somehow as being a special label.

1 Like

That’s actually a very good idea that I would like too as solution, if it is possible.
The commit message keywords should also reflect that feature if possible in my opinion.

Have you already opened a feature request related to that: - otherwise I will do?

(Be aware that they will take quite some time to reply to the feature request, since they have quite some support volumne at the moment it seems.)
Edit: I already submitted it now.