Named tags in BLOM master?

[TomasTorsvik]

Question from Mariana:
Could we start having named tags on blom master? It would be much easier to reference these as opposed to hashes and would make this consistent with the rest of the NorESM component tagging.

[TomasTorsvik]

I think it is fine to have more tags. Any suggestions for a naming convention for the tags?

[jmaerz]

Hi @TomasTorsvik , just as a starting point: https://semver.org/ - but maybe NoRESM has its own convention?

[TomasTorsvik]

I think the "MAJOR.MINOR.PATCH" convention is useful for code releases, and this is what we follow (except we haven't used PATCH). As I understand Maraina, the question is to have other tags in BLOM that are not necessarily related to a release version, but can be referenced when doing e.g. "checkout_externals" with a modified Externals.cfg file.
@mvertens - maybe you can explain better how you see the use of these tags?

[mvertens]

Lets say we have a blom tag naming convention on master as: blom_x.y.z (you already have v1.3.0 - so we could keep that as well).
Every commit to master would update the z now. And then you would decide when you wanted to update y and x for some of the commits to master.
The updating of z can be done automatically in github actions. See
https://github.com/NorESMhub/WW3/blob/noresm/.github/workflows/bumpversion.yml

[TomasTorsvik]

OK, this seems like a reasonable solution to me.
@matsbn , @JorgSchwinger , @jmaerz , @milicak
do you have any opinion regarding this way of making tags on the master branch?

[jmaerz]

I don't have a strong opinion on this - the advantage that I see is that the tagging allows to better identify the time line and getting a grasp of code change from the tag, while sha would be shorter to type, but being rather random and without the additional meaning.

[TomasTorsvik]

@mvertens
I see one potential drawback with tagging every commit in master. When I look at the commit log I frequently use git log --oneline --decorate --graph --simplify-by-decoration (or the emacs magit equivalent to this command) to get a log with only the last commits on each branch. But tags are also "decorated" in the log, so with automatic tagging it is less straight forwad to hide "intermediate" commits on the master branch. I'm not aware of any solution where you can either hide all tags or only include the head of each branch. Do you know if this is possible somehow?
This is perhaps only an issue for me, but it would be great to have this functionality available.

[gold2718]

When I try that command on a Blom clone:

git log --oneline --decorate --graph --simplify-by-decoration origin/master

I get:

* 0b07349 (origin/master, origin/HEAD) Move main sediment parameters to mo_param_bgc (#297)
* 1d71682 (master) Merge pull request #281 from mvertens/feature/refactor_ifdefs3
* e343fee (origin/feature-langmuir) Added diagnostics of wave fields received from CESM coupler.
*   0749d29 Merge branch 'master' into feature-hamocc-vsls-upd
|\  
* | dd8bbe8 (origin/feature-hamocc-vsls) Merge pull request #93 from tjiputra/feature-hamocc-vsls
| * 0c7f492 (tag: v1.1.0, origin/release-1.1) Merge pull request #76 from AleksiNummelin/feature_highres
|/  
* a8a7e94 (tag: pre-v1.0.0) Merge pull request #24 from DirkOlivie/master
* 4c83041 (tag: blom0_0_001) Merge pull request #10 from matsbn/feature-inputdata
* 56d027d (tag: blom0_0_000) Merge pull request #6 from matsbn/feature-blom-lgpl
* 8d1b58b Initial import of structure. Code is based on ccsm4_0_alpha31

Is that the output you see that you would like changed? If not, what am I doing wrong in my command line?

[TomasTorsvik]

Yes, that is the output I get as well, and this behavior is what I want to preserve.
The problem with having automated tagging is that you will get [tag: blom*..] all over the master, so the branch heads will get lost in a long list of tags, i.e. --simplify-by-decoration will not simplify if everything is decorated.
There may be a solution with adding --decorate-refs-exclude='/refs/tags/blom*, which seem to work on the command line, but I haven't found a magit equivalent (https://git-scm.com/docs/git-log)

[TomasTorsvik]

OK, it seems it should be possible to exclude the tags from the log after all, so this is probably a non-issue.

[jmaerz]

To bring the discussion here:
Jörgs comment (#297 (comment))

Regarding the tags: What would be the relation between these automated tags and our releases? We have currently tagged releases v1.0.0 to v1.3.0 and we are working towards v1.4.0 (the last CMIP6 backwards compatible release). So I would find it confusing to have the automated tag v1.0.0 associated with our release v1.4.0 - is there a reasonable way to synchronize this?

Then it would be at least logical to start with blom_v1.4.0.

[TomasTorsvik]

I agree, we should have some consistency in numbering between the automated tags and last release version.

[matsbn]

I can see the benefit of more tags. As I understand this would be for tagging development snapshots, not releases, so I think we should not directly increment on the v[MAJOR].[MINOR].[PATCH] tag names we use for releases (although we have no patch releases yet, as pointed out above). Maybe a tag name containing "dev" in it? I'm no fan of having the component name as a prefix of a tag name, as it just seems redundant because a tag without a reference to the repository is meaningless.

Great if we can wait to decide on this until after 15 Nov :)

[mvertens]

Waiting until after 15 Nov makes sounds fine. Thanks for all of the input on this topic.

[mvertens]

The recommendation from the meeting as I understand it:
releases: v1.5.0 , v1.5.1 (bug fixes) .... v1.6.0
development: dev1.5.0.1, dev1.5.0.2, (automated by github actions) ..... dev1.6.0.1

As an example:
we tag v1.5.0 now
we start release testing and there is a problem
we create a release branch and update the code and tag it as v1.5.1

[TomasTorsvik]

I have created dev1.4.0.1 on the master branch now.

[TomasTorsvik]

@jmaerz , great, I think we are on the same page here. Hope we have everyone else on board as well. I think this will become clearer once we start using this system, or perhaps, we will see clearer if there are any pitfalls.

[mvertens]

@TomasTorsvik - thanks for adding the clarifications.
@jmaerz @matsbn @JorgSchwinger - I implemented the new github actions for automatic tagging - but after talking to @TomasTorsvik this morning we feel that we should defer the automatic tagging for now until we are all comfortable with the new tagging scheme. I can easily do PR with the new automatic scheme once that is the case.

[TomasTorsvik]

@mvertens - Thanks!
I suggest we include the dev tags "by hand" until the v1.5.0 tag, which probably will come next week, and make that a target starting point for automatic tagging, i.e. to be introduced as dev1.5.0.1. Is that OK with everyone?

[jmaerz]

@TomasTorsvik basically like this:

[jmaerz]

Dear @TomasTorsvik, @matsbn, @mvertens and @JorgSchwinger , I guess, during and after the discussion, I was/am a bit perplexed that the new system shouldn't hold any information on code changes in the development master branch. Flagging for answer changes would also enforce the regression testing a bit. But I do see that the maintenance costs and overhead are probably too high for this, so just go ahead from my side.

[TomasTorsvik]

@jmaerz @matsbn @JorgSchwinger @mvertens @milicak
Hi, I have continued to tag occasionally "by hand" according to the scheme outlined in the figure above, but not for every merge commit on master. I don't see any problems with having more tags, but it is a bit annoying that github always produce tar and zip archives for each tag. The size of these archives are about 1.6MB in total, so it will take a while before this becomes a real issue.

I still wonder if we need to tag everything, but it would be the easiest and most consistent way to proceed. I also see that the tags may become more useful in the development phase towards NorESM2.5 and NorESM3, if we make more rapid changes in the Externals.cfg file.