increment version number on CITATION.cff

[BeritJanssen]

To keep version numbers up to date in CITATION.cff, I thought to update the version number upon every merge to master. This may only a partial solution for keeping CITATION.cff up to date, as the doi from zenodo will still point to the old version. BUT we may use the overarching DOI for I-Analyzer, 10.5281/zenodo.10261620, which seems to point to the latest version always. NB this solution uses sed, which has its own regex syntax. [[:digit]] is equivalent to \d, and {1,} means "one or more matches"

[lukavdplas]

Is the motivation of this workflow that we won't need to update the citation file manually?

[BeritJanssen]

Yes, precisely.

[lukavdplas]

Ah, ok! To be honest, I don't personally see a need for that automation. Going through all the steps of a release takes 30 minutes on a good day, and this is a really trivial step. But I have no objection to it either.

Comments on execution:

• The update happens on the push to master - if you use git flow, the release tag will precede that, so the example citation on Zenodo (which is based on the release tag, not the master branch) would always show an out of date version number. Perhaps this could be resolved by running the workflow on pushes to release/* instead?
• I'm not great with the git CLI, but this looks like it commits to master but not develop?

Some suggestions for consistency:

• Make sure to update the release checklist as well.
• The manual page on citation refers to Zenodo, but if that Zenodo is going to consistently show an out-of-date version number, the manual shouldn't link to it.
• CITATION.cff also specifies the release date, which should also be updated. I don't think there is much reason to automate one but not the other?

[BeritJanssen]

Ah, good points. Triggering the workflow on push to release (and hotfix?) branches will also mean we'll integrate the changed citation file in develop and main/master both. Will update that & also automate the date. Should I additionally change CITATION.cff to point to the top-level I-Analyzer doi, rather than the latest version? I can also update the manual's link to that page (which lists all the versions). Now the manual points to an outdated version, indeed.

[lukavdplas]

Should I additionally change CITATION.cff to point to the top-level I-Analyzer doi, rather than the latest version? I can also update the manual's link to that page (which lists all the versions). Now the manual points to an outdated version, indeed.

Yes! :+1:

[BeritJanssen]

Turns out the doi in the CITATION file was already correct, the badge on our repo page is too. So only adjusted the link in the documentation.

[lukavdplas]

Neat!

Two more (small) comments:

• The release checklist should mention that you now need to push the release branch to github.
• What happens if the citation/date are already up to date? (Most likely because the release branch is pushed multiple times.) There shouldn't be a commit in that case.

[BeritJanssen]

I thought that the release or hotfix branch would always be pushed, as that's the one we'd be testing on the test server prior to merging it to master & develop. Doesn't git flow release publish, as mentioned in the documentation do a push?

Good comment about committing when there is no change - but if you do git commit -a -m "some message" without any changes, git won't create a commit but respond "nothing to commit, working tree clean".

[lukavdplas]

I thought that the release or hotfix branch would always be pushed, as that's the one we'd be testing on the test server prior to merging it to master & develop. Doesn't git flow release publish, as mentioned in the documentation do a push?

True, but that section of documentation also suggests you publish the branch for one specific purpose. If there is another reason to publish the branch, it doesn't hurt to mention it, I think.