Discussion on role of NorESM master branch

[DirkOlivie]

Introduction
There exist different branches in NorESMhub/NorESM (shortly described in the README.md file) : master, noresm2, release-noresm2.0.2_keyClim, ... . E.g., the noresm2 branch is a version of the model which still reproduces bit-for-bit CMIP6 results (but gets updates over time when new machine settings, new diagnostics, new compsets, ... are added).
However, it is not so clear what the role of the master branch should be.

Possible role of the master branch
What should be in the NorESMhub/NorESM master branch? Should this be a branch of the model that :

• gives a stable and scientifically tested version of the model when a new user downloades the model?
• gives the most recent running version of the model?
• gives only an overview (via the README.md) file of the other existing branches?
• ...

The aim of this discussion is to gather opinions on what the master branch should be, and possibly arrive at some concensus.

Questions

• So please, give your opinion on the role of the master branch in NorESMhub/NorESM.
• Please list advantages and disadvantages of possible different approaches.
• Is there a role for Externals_continuous_developments.cfg (which refers mainly to branches of the sub-components) compated to Externals.cf (which refers mainly to tags for the sub-components)?

[TomasTorsvik]

NorESM is a bit unusual since it mainly contains references to external components, not the model source code itself. So the model configuration is mainly governed by whatever is in the Externals.cfg file.

I think most users would want to start from a stable and scientifically tested version of the model and configure this for their own experiments, so from this point of view it makes most sense that the default setup (i.e. master branch with default Externals.cfg) provides a stable version.

As for experimental setups, we could have separate branches for this, or provide alternative Externals_experiment.cfg files in master. It may be easier to maintain a single master branch with several External_experiment.cfg files than having multiple branches with slightly different Externals.cfg files.

[adagj]

Can we please rename master to main?
master is kind of outdated: https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main

[TomasTorsvik]

Can we please rename master to main? master is kind of outdated: https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main

Technically, it should be straight forward for one of the repository owners to do this in the branches overview:
https://github.com/NorESMhub/NorESM/branches

However, it should be announced and a date should be set, because anyone who has cloned or forked the NorESM repository will lose the upstream link to the master branch.

[TomasTorsvik]

Alternatively, we could just create a main branch on the current master and set main as the default branch. Then we would not risk losing existing links, but master would remain as a stale branch in the repository.

[MichaelSchulzMETNO]

I believe one main question is : What is the purpose of the noresm-main/master branch?
And then - if there is a main branch called "latest" in the documentation, how to point more effectively to the other branches? Currently you have to scroll down in the "latest"-documentation to click on the tiny "noresm2" button to get the noresm2 documentation showing up. I have no perfect solution, but the main branch should at least explain upfront how to find eg the documentation on the latest releases of NorESM2, or ?

[TomasTorsvik]

@MichaelSchulzMETNO @matsbn @adagj @DirkOlivie @gold2718 @mvertens
I wanted to update the description of branches in the README.md file on the master branch, but I'm actually not sure how we use the branches at the moment.

• It seems master is not used for active development, but only as an entry point on github and pointer to documentation. I think this is fine as long as we all agree to do it this way.
• We have noresm1, noresm2, noresm_landsites and noresm2.2 as permanent branches corresponding to model versions that will not be merged into future development versions. The idea with these branches it that we can still make technical updates (e.g. non-answer-changing bug fixes, porting to new HPCs), but otherwise they remain as stale branches.
• Now we also have noresm_develop, noresm2_1_develop and noresm2_3_develop which represents different development tracks. I don't know what development noresm_develop is tracking, but at least noresm2_1_develop and noresm2_3_develop are fairly self-explanatory. However, I think it would be more consistent if theses branches were named noresm2.1 and noresm2.3, as we anticipate that these branches will become permanent stale branches at some point. Or is there a point to having the "develop" name as long as a version is still under development?
• By the reasoning above, should we now rename noresm2_1_develop -> noresm2.1, as we already have a noresm2.1.1 release?
• We have a few branches ported from CESM (cesm2_0_beta06, N2dev_port_from_CESM2.2.0). Do we need to keep these in the NorESM repository? Are they needed temporarily for ongoing development or just as reference points that we want to keep permanently?
• Lastly, we have the other feature or bug fix branches (feature-noresm2.0.2_KeyClim, feature-noresm2.0.2_KeyClim_cloud, feature-noresm2.0.2_ozone, pe_bug_fix). Feature branches and bug fix branches should be merged into development branches and then be removed. However, I'm not sure these are really feature branches, at least for feature-noresm2.0.2_KeyClim we have code releases based on this branch. I find it confusing that we do not seem to separate between the different categories of branches by naming conventions, so it would be good to clarify and agree on a standard naming convention that we use for the branches.

[mvertens]

• noresm_develop is tracking noresm2_5.
• I am fine with renaming if if we come up with a consistent scheme that we can follow in the future.
• I completely agree about merging the feature branches into the develop branches and then removing them.
• I think the key point is creating a naming convention that is agreed to and used consistently.