stfc / PSyclone

Domain-specific compiler and code transformation system for Finite Difference/Volume/Element Earth-system models in Fortran
BSD 3-Clause "New" or "Revised" License
104 stars 27 forks source link

Automatically update version number by appending git hash #2724

Open arporter opened 2 days ago

arporter commented 2 days ago

At the telco today, we agreed that the PSyclone version number (stored in src/psyclone/version.py and also in doc/reference_guide/doxygen.config) should have the git hash of the last commit (to master) appended to it. This will enable people to see when they are working with a version checked-out of GitHub, as opposed to a released version.

We could do this manually as part of the end-of-the-review process but it would be much better if we could automate it using a GitHub Action.

hiker commented 1 day ago

I've found https://stackoverflow.com/questions/3442874/in-git-how-can-i-write-the-current-commit-hash-to-a-file-in-the-same-commit. In short, we can't add the hash before writing the file (since adding the hash will change the hash). One solution mentioned was to use the previous hash. Or we could use the post-checkout hook? Not sure how this works with updates, merge, cherry-pick etc. git attributes are mentioned, but they apparently need to be installed each time manually(?)

On https://softwareengineering.stackexchange.com/questions/333680/how-to-version-when-using-trunk-based-development it was mentioned:

To differentiate "trunk-builds" from official releases, it is common to add a suffix like snapshot-DATETIME to the version number.

Not sure if this can be automated (i.e. modified automatically on commit) - I did a brief search, and there seems to be odd cases where modifying file might have unexpected side effects. I hope one of you knows more of git hooks than I do :)

I am getting the feeling that just adding "-alpha" to the version number after a release might be the easiest option (and would work for me, all I need is to distinguish current master from the last release). It would also follow the semantic versioning standard (https://semver.org/).

One other idea: version.py tries to run and interpret git branch (we can't use git branch --show-current, it provides no output in case of a tag or hash based checkout). Possible outcomes (not sure if this list is really complete)

arporter commented 1 day ago

Thanks for thoroughly investigating Joerg. I like the idea of sticking to SemVer but I'm worried we're going to have e.g. 'alpha' versions of releases that will never actually exist. e.g. at the moment we should probably be at 3.0-alpha which is fine as we will definitely release 3.0. As soon as that is out of the door, we bump the 'working' version to 3.1-alpha. Say we then discover a bug in 3.0 that requires an immediate fix so we need to release 3.0.1. Do we backport the bug fix to 3.0 and then release that or does it go into 3.1? I guess the answer will depend on how urgently the bug fix is needed?