Automatic versioning
We already discussed basic options to do automatic versioning and I explored a few of them. I want to use this to document the discussion process and also the pros and cons that I found as well as some issues to keep in mind. @florian.woerter @yagmur.sevilmis @matthias.myrtus
The basic idea:
- update patch version with each merge to the master branch
- allow suppression of a new (patch) version via tag in the commit message (for trivial/editorial changes)
- manual bump of minor and major version based on arbitrary conditions
Would be nice:
- tag each (patch) version to make it easier to find a specific version deployed somewhere
Technical aspects:
- CMake needs to get the version information - either from a file or from the git tags
- but: CMake needs to pick up changes in the version even if no CMake files were modified (tricky either way)
- updates to the VERSION file from the CI pipeline may lead to issues when the currently running pipeline does not reflect the head of the master branch, e.g. because an additional merge was applied while the previous was still running
- big plus for tags: they are simply applied to the current state/snapshot
Observations so far:
- tags can be automatically created with a script as part of a separate CI stage
- but: requires a deploy token and SSH authentication to have write access to the repository
- CI pipeline is run again for each tag, however if tagging is restricted to master it will not be applied again
Issues:
- if multiple tags are assigned to the same commit, the older is picked up by the versioning script
- this is harmful if an already automatically tagged commit gets a manual version pump with a separate tag to the same commit
- might not be such a big deal if we also update the changelog with each manual bump and tag the updated commit separately (with the additional
[version skip]
tag)