Release workflows

[niklaspandersson]

I would like to start a discussion on how we handle releases. Especially the practical workflow.

We are fortunate enough to be in a situation where there is actually quite a lot of activity in the repository. Apart from being super exciting, It also exposes the need for revising some of our workflows.

In the situation we're in now, releasing directly from master blocks the progress of new feature (that might not be mature enough to go into a release). Could we maybe create a separate branch for the release once we know which features we want to include, so that work on new features can continue on master. Instead of branching as part of the release?

If someone has suggestions of other workflows that we can use to allow for work to continue when a release is pending we can discuss that here as well.

[Julusian]

My general approach to this has been to create the v2.4.x (aka release branch) at some point when it has felt necessary. But there isn't a well defined time to do this other than when I feel like it. (It has been a while since there has been significant changes from elsewhere, so a loose flow has worked well for me)

So I have created the 2.5.x branch now, please re-target the PR for anything you think should go into that, and we can figure out what is left before the release from there.

[niklaspandersson]

Great! Thank you. This is perfect

[Julusian]

Writing it here in case anyone is curious, my steps for performing a release are to:

• Cherry-pick any commits between the release branch and master as needed (in both directions), merging the branches is too full of merge conflicts once they have started diverging.
• Update the changelog in both the release branch and master. Commit and push this
• Create a temporary branch off the release branch, and make a commit like fd9168c
• This temporary branch should be tagged and just the tag pushed. The branch can now be deleted
  I do this because we don't want the changed CONFIG_VERSION_TAG to be in the release branch, and this avoids that
• Create the release on github, (based on the format of the previous one) using the changelog as the bulk of the text.
  The windows binary can be grabbed from the github actions build of the tag.
  The linux binaries are fiddlier and is not a well documented flow