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).
Solved! Solved! Go to Solution.
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.
Mark helpful posts with Accept as Solution to help other users locate important info. Don't forget to give Kudos for great content!
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:
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:
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!
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.