Add git commit sha to displayed version (useful when running from source)
fedelibre opened this issue · comments
Looking at the git history, the version bump is usually made just before a new release.
IMO the version bump should be made after a release (of course, for the next unreleased version). Why? Two main reasons:
- If I run Frescobaldi and want to test python-ly from source, I can be sure that this is really the case if the git version shows an unreleased version.
- No risk of forgetting the version bump when you do a release :-)
@PeterBjuhr What do you think? Can you do the version bump?
No, bumping versions before a release causes all sorts of problems later. People start using a HEAD version for some bug fix then later think they are running the later release and report against it.
The best way to handle this is with a VCS versioning system that shows the exact commit with the last release tag + N commits + commit sha. If this project doesn't want to adopt an SCM aware automated version tag then saving the bump until just before release is the right way to go.
No, bumping versions before a release causes all sorts of problems later.
You mean after?
adopt an SCM aware automated version tag
Could Github actions be used to synchronize the release and the code change?
No, bumping versions before a release causes all sorts of problems later.
You mean after?
No, I meant before, but more specifically long before. The version bump should be at or immediately prior to the release tag, not long before (e.g. at the very end of the dev cycle not the beginning).
adopt an SCM aware automated version tag
Could Github actions be used to synchronize the release and the code change?
Yes, but that's also unnecessary. The correct way to handle this is to remove the version info from the code entirely and rely on a build system that deduces it from the repo tags on every build. This can be done both for Git based source builds and tarballs if done correctly, but takes a bit of careful tooling.
Thanks for clarifying!
The best way to handle this is with a VCS versioning system that shows the exact commit with the last release tag + N commits + commit sha.
I agree, this is a good common practice.
Since this project uses Python's setuptools build system, the logical step would be to adapt the versioning using setuptools_scm and adjust the release workflow around that.