NorESM2.1

[MichaelSchulzMETNO]

Dear all,

I suggest to banch off to NorESM2.1 now for future development of NorESM.

I have thus merged noresm2 into master, and created then a new branch noresm2.1 . At the moment noresm2, master and noresm2.1 are equal.

The noresm2 branch should be only updated for non-answer changing changes wrt to CMIP6 model results. Such changes should be reviewed.

If changes are to be made for all the three branches (eg documentation), this is of course a bit cumbersome. Suggestions how to proceed are welcome.

If there are suggestions, please comment. I would like "us" to send in some days a general email to noresm email lists anouncing the way forward.

Michael

[TomasTorsvik]

I agree with Mats about the structure, to do development on master and create the noresm2.1 branch when we want to tag a new version. At the moment master and noresm2.1 point to the same commit, so the noresm2.1 branch can be removed without consequences.

[TomasTorsvik]

Meanwhile there has already been an addition to the noresm2 branch. I think an announcement is urgently needed not to stop contributions to this branch in the future.

[MichaelSchulzMETNO]

Suggestion for an explanation in any announcement:

What is the purpose of the branches?

noresm1: contains the NorESM1 code and documentation

noresm2 : refers to the CMIP6 model version, release 2.0.2, but may contain further changes which make the CMIP6 model version non-answer changing, but more easy to handle, eg via new machine settings etc

master: contains the latest validated model version

noresm[abc]: contain development banches, possibly linked to a project, naming can be free, but should purpose of branch must be documented in readme file for master branch.

noresmx[.y]: contains a prerelease and release branch

[MichaelSchulzMETNO]

Alternative suggestion
noresm1: contains the NorESM1 code and documentation

noresm2 : refers to the CMIP6 model version, release 2.0.2, but may contain further changes which make the CMIP6 model version non-answer changing, but more easy to handle, eg via new machine settings etc

master: contains the latest developments, based on the latest release, model changes incorporated into master are expected to work technically, and form partially the basis for the next release

noresmx[.y]: contains a prerelease and release branch

[TomasTorsvik]

I would prefer version #2. I think it is easier if all developers mainly contribute to a single master branch. If a feature is not included in release noresm2.1 (for example), you can just continue development on master and get it into noresm2.2. If we develop on the release branches, we run the risk of (a) the release is delayed because of a few incompleted tasks, or (b) an unfinished development task must be moved from release branch noresm2.1 to noresm2.2.
We also avoid doing a huge merging from the release branch to master, as we recently did after the release of noresm2.0.2.

[MichaelSchulzMETNO]

After some discussion, there was some majority for keeping the master as the development branch for the NorESM repository. Have adapted the structure accordingly, deleted noresm2.1 branch for now and updated the Readme.