Create `release` github branch

[glemieux]

Task description

With ctsm moving to a develop/release branch (aka "gitflow") workflow and the need to create and maintain a release tag for the clm6 release, the FATES team has decided to move to a similar gitflow strategy. We will use a stable release branch to hold release tags and keep the main branch for continuous development. This will allow us to create fixes to the release branch that HLMs can point without having to disentangle the fix from current development work. Any fixes pushed to the release branch can then be merged into the main development branch.

[glemieux]

We should also make sure to start tagging releases on the user's guide to avoid confusing users with any changes to the bleeding edge development. See NGEET/fates-users-guide#105.

[ekluzek]

I'm really glad you added this. It'll help to have the process for how FATES releases are handled. Some of the questions that I'd like to have you work out are:

• Do release branch tags have a different naming convention? What will be the name of the branch?
• Do you just create release branch tags when needed for one of the HLM's or on another cadencee?
• Are there additional testing or review requirements for release tags?
• Would there be a need to have a separate release branch for each release tag series? Or just one general branch?
• Do release branch tags get updated to a release on github and turned into a DOI with Zenodo?
• Do FATES releases have a set of simulations that go along with them? And if so what does that look like in terms of options and HLM's run with?

In general it seems best to make things as simple as possible, until there's a strong need for increasing complexity. I think for example you can get away with a single release branch for FATES. But, if each HLM will need a different branch that might need to be different. It would be good if there can be a single FATES release tag that can support all HLM's. Which might be possible becasue the HLM's will largely need a release tag around the same time coinciding with CMIP cycles.

I think this would likely be good if you and I chat about this a bit @glemieux and also talk about some of this for the larger groups later. I've been doing the release branch stuff for CTSM and CESM.

The guidelines for minor version updates we have for CTSM might help for ideas:

https://github.com/ESCOMP/CTSM/wiki/Minor-Version-Update-Protocols