Development branch for changes that break backward compatibility

[TomasTorsvik]

Hi,

I think we have several things we would like to change in the code which will break backward compatibility with CMIP6. At least I know some of the issues or iHAMOCC has been kept on hold for this reason. Would it make sense to create a new development branch where we fix these issues?
It will be a drawback to maintain both master as CMIP6 backward compatible and a new development branch, but I expect that master will then morph into release-1.3 somewhere down the line, and the development branch will become the new master branch. In any case, I can see the need for maintaining two branches in the future as well, one CMIP6 backward compatible and one with all new developments. The question is when and how to make the transition.

[TomasTorsvik]

@JorgSchwinger @jmaerz @matsbn @milicak
Hi,
it seems that the number of CMIP6 breaking bug fixes are piling up, so I would like to create a new development branch in BLOM/iHAMOCC for code contributions that break backward compatibility with CMIP6. I suggest that we keep the master branch backward compatible for the time being, and continue to update master with non-answer-changing commits, and update the new development branch from master when needed.

The questions I have, that I would like your feedback on, are:

1. Do you agree that it makes sense to set up a common backwards-breaking development branch now, or do you have any strong point of objection to doing it this way?
2. Should we set up one common development branch for BLOM/iHAMOCC for all backwards-breaking code changes, or should we make separate branches for the physics and BGC? I think it is cleaner to have one common branch, but either way should be fine.

[TomasTorsvik]

@JorgSchwinger @jmaerz @matsbn @milicak
Hi,
I discussed this today this with Mats and Jöran, and for now we will set up a development branch for iHAMOCC that contain changes that are not compatible with CMIP6. I have therefore created a new branch in the main repository: feature-hamocc_beyond-CMIP6.

We still plan to make a (final?) release of BLOM/iHAMOCC that is backward compatible with CMIP6, so all code changes that are not answer changing should still go to the master branch. We will submit answer changing code to feature-hamocc_beyond-CMIP6 and update this from master from time to time. After the next BLOM/iHAMOCC release we should decide if we want to have just a single beyond-CMIP6 branch for BLOM/iHAMOCC or if we want to have separate branches for physics and BGC.

[JorgSchwinger]

Sounds good, thank you

[TomasTorsvik]

@JorgSchwinger @jmaerz
I merged the master branch to feature-hamocc_beyond-CMIP6 today (#190), but Jöran's PR (#189) still contains a long commit history. In order to avoid this problem in the future, I suggest the following

1. Update feature-hamocc_beyond-CMIP6 regularly from master. This time I asked for a review for the merge PR, but I'm not sure this is necessary, since we do a code review anyway when merging new code into master. However, if someone is preparing code to merge into feature-hamocc_beyond-CMIP6 it can be disruptive if suddenly there is a new merge from master, so maybe it is still good to do a PR also on merge PRs, to get a "green light" from everyone before changing the branch?
2. It may be an advantage to start new development branches from feature-hamocc_beyond-CMIP6 instead of from master, at least if you plan to implement something that is not compatible with CMIP6 output.
3. New features that do not break backward compatibility can still go to the master branch (e.g. new optional features or adding options to an existing feature), as long as these can be enabled/disabled (preferably through the namelist input file).

[jmaerz]

Hi @TomasTorsvik and @JorgSchwinger , shall we opt for an even automated merging of master into beyond-CMIP6? - as in, every time, something changes in master, we merge it also into the beyond-CMIP6 branch immediately (not only 'regularly', whatever this means)? - I ask, since otherwise it's easy to run into merge conflicts.

[TomasTorsvik]

Hi @jmaerz and @JorgSchwinger , if we merge master to beyond-CMIP6 for every change we will end up with a lot of merge commits in the feature branch, and considering that many changes enter into master from a merge commit we would potentially have two merge commits for every code change. I would prefer to update feature-CMIP6 only when needed, which would be

1. just prior to making a new branch in beyond-CMIP6 for new code contributions
2. just prior to merging new code contributions into beyond-CMIP6 (if there have been any changes to master after the branch was made).

I'm not entirely against merging after every update of master, but I fear that this will mostly result in adding noise in the commit history, and the conflicts will have to be resolved anyway if they occur (although with more "atomic" commits the conflicts should touch fewer files).

I also suggest that merging of master to beyond-CMI6 can be done in a PR without code review (i.e. the person making the merge PR can do the merging immediately without waiting for reviews), unless the merging results in a conflict that must be resolved. There is no dry-run option for git merge (that I know of), but a similar outcome can be achieved by doing:

   $> git merge --no-ff --no-commit <branch>
   $> git diff --cached
   $> git merge --abort

This can be used to check if a merge will result in a conflict before issuing a PR. The PR also includes a statement about conflicts in the "merge" section at the bottom, but I'm not sure I would rely on it (although, it seems to be working OK).