New BLOM/iHAMOCC release-1.7 branch for NorESM2.5?

[TomasTorsvik]

Jörg, Jöran and myself were discussing if it would be useful to create a new release-1.7 branch from master, targeting the NorESM2.3 release. We already created release-1.6 for this purpose before summer, and there have been more changes in the master branch since then, but we still have MCT as an option.

Some suggestions for making a branch:

• Create a branch today, including all changes since departing from v1.6.1
• Create a branch before disposing of the "cgs" option
• Create a branch before disposing of MCT

Today a noresm2_3_alpha01 tag was created, and we should make sure that any changes from BLOM/iHAMOCC does not interfere with testing and tuning towards a NorESM2.3 release. Hence we should probably avoid introducing code changes that change default settings to a large extent.

Linked issue: #340

[gold2718]

Is the release-1.6 branch not appropriate for this? Is it for NorESM2.1?

[TomasTorsvik]

Is the release-1.6 branch not appropriate for this? Is it for NorESM2.1?

At the moment we have

release-1.4  ->  NorESM2.0.X
release-1.5  ->  NorESM2.1.X
release-1.6  ->  NorESM2.3.X
master  ->  NorESM2.5.X

Until now we have tried to do only "technical" updates, minor bug fixes and optional additions on release branches, and use master as the main development branch. I think it will become messy if we start allowing the release branches to include development changes, so I would prefer a new release branch.

Once we remove MCT, I think it would make sense to start with release-2.0, so that release-1.X remains MCT-compatible also in the future.

[gold2718]

If the release-1.6 branch is already targeting NorESM2.3, what is a release-1.7 branch needed for?

[TomasTorsvik]

If the release-1.6 branch is already targeting NorESM2.3, what is a release-1.7 branch needed for?

If we make a branch release-1.7, it would be a replacement for release-1.6, targeting NorESM2.3.

[gold2718]

If the release-1.6 branch is already targeting NorESM2.3, what is a release-1.7 branch needed for?

If we make a branch release-1.7, it would be a replacement for release-1.6, targeting NorESM2.3.

Sorry for being slow, why not just update release-1.6 given that we are still working on the initial NorESM2.3 release?

[TomasTorsvik]

If the release-1.6 branch is already targeting NorESM2.3, what is a release-1.7 branch needed for?

If we make a branch release-1.7, it would be a replacement for release-1.6, targeting NorESM2.3.

Sorry for being slow, why not just update release-1.6 given that we are still working on the initial NorESM2.3 release?

Not at all, I suppose it all comes down to naming conventions and what we think these should mean.

We had a discussion about naming convention about a year ago, in #295, and we have mostly followed the scheme outlined here after that, i.e. with a convention on naming the release branches of v[MAJOR].[MINOR].[PATCH]. I suppose we never defined exactly what goes into [MAJOR], [MINOR] and [PATCH], but in my mind a [PATCH] should be something fairly trivial.

What I like with doing it this way is that you can follow the progression of the code by looking only at the change logs associated with the vX.X.0 tags. So for this reason I would prefer to make a new branch release-1.7 with a well documented v1.7.0 tag rather than having the same content in a v1.6.6 tag.

The downside is that we will have more release branches, but I think we only need to actively maintain a few of those. The release branches release-1.0, release-1.2 and release-1.3 are stale and in a practical sense deprecated at this point. We should probably document this in some way, and eventually archive the stale branches.

[TomasTorsvik]

I have now added an entry in issue #340 for development that we can put into a new v1.7.0 tag. Feel free to add/edit the list.

[jmaerz]

I suspect that this issue could be rename to NorESM version 2.5? (and be closed soon)

[TomasTorsvik]

@jmaerz , @JorgSchwinger , @matsbn , @milicak
I will go ahead and prepare the v1.7 release now.