Showing results for 
Search instead for 
Did you mean: 
Copilot Lvl 2
Message 1 of 4

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

Solved! Go to Solution.


  • 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).

3 Replies
Community Manager
Message 2 of 4

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

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.


Thank you for your perspective and your contribution!
All the Best

Mark helpful posts with Accept as Solution to help other users locate important info. Don't forget to give Kudos for great content!

Community Manager
Message 3 of 4

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

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!

Copilot Lvl 2
Message 4 of 4

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

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.