Feature: Branched release model

[yardasol]

Background and motivation

In my meeting with @munkm today, we talked about how micro version releases should really only be for bug fixes and feature improvements. The tags for our releases thus far all point to commits on the master branch.

Description of idea

We discussed switching to a release model where, for each version:

1. when all the issues and PRs in a milestone are closed, we make a new branch with the same title of the milestone
2. We then create a draft release for the milestone pointing to the newly created branch.

This is a bit more work, but we can easily automate it with workflows. Having each release on its own separate branch also means that if we are actively working on a milestone for the next release (on master( and we find a bug, we can easily create a new branch to fix the bug, and the PR into both the master branch.

Having the previous releases decoupled from the master branch means we can backport bug fixes and iterate to a new micro version relatively easily.

Using this release model may also simplify implementation of #108 and #110.

Implementation details

In order for this to work, we'll need to do two things:

• Specify that this is the model we use in the developer's guide in the docs
• add workflows to automate wherever possible (workflows introduced in Doc changelog #115 are a good starting point)

Potential snags

This could totally mess up the way docs are deployed to github pages.

@munkm @LukeSeifert @arfc/saltproc please discuss.

[yardasol]

Make sure to add steps in the workflows that change the _version_extra to '' from 'dev'

[yardasol]

New idea:

update next-release minor.yml with the following steps:

1. Create a new milestone, branch, and release witth the same name. Point the release towards the new branch
2. Perform the remaining tasks currently in next-release-minor.yml

This way we can have separation of concerns with the workflow in #129