I can't agree with having a source file include the tag. It is an eternal source of merge conflicts and pain, unless you take steps to automate it. And in that case, does the file add much value anymore?
My personal experience with go modules and versioning has been really positive. In that ecosystem - you only define your major version in the mod file and rely on the VCS for everything else.
>Tag push permissions
Agreed entirely on restricting tags (they tend to have meaning and expected semantics outside the repo, which makes them risky), but also! Teach people more about git, or unix CLI patterns in general. `git log test` is ambiguous about it being a tag (or branch) or file/folder, but `git log -- test` is not. `--` as an ambiguity-preventer is a very common pattern, it works in many, many CLI tools.
---
One that hasn't been included here: don't rely on tags for any kind of business logic, if you have literally any way to avoid it.
Tags are mutable, and do not have a history of when you changed them. They're plenty handy for "human, enter a thing to use" purposes, but you should immediately turn that into a commit sha and then only use that commit sha.
Another important reason to use annotated tags: Tags without annotation are just a reference to a commit and cannot contain any metadata, such as the release date or the release authorship information.
Our company uses a tag, quite improperly, to indicate our "last successful build" on each branch, so our local builds can pull e.g. compiled .o files from that build and speed up the local build process. A tag is improper since it needs to move with every successful build. All relevant commands need --force to update it and it can rarely create headaches when machines disagree.
I believe the right thing functionally is a child branch, updated automatically with either a merge or a force-push on new successful builds. But it feels not quite right conceptually, and it's harder to explain to new developers (who can already get overwhelmed with handling multiple branches). Is there a non-branch solution for having a moving unique label?
Annotated tags are a good idea, they also happen to be a requirement when signing tags. You can create empty message signed annotated tags with `git tag -sm "" v123-my-signed-tag`.
I once made a blog post / video around signing and verifying your commits and tags at: https://nickjanetakis.com/blog/signing-and-verifying-git-com...
Although not git-tag specific, if you want to see a great rant on semantic versioning, I can highly recommend Rich Hickey's.
Since the OP is here, I am confused.
In the first section, are you saying that:
a) tags can and should be named to include the sha at the end; and
b) git commands silently discard everything before "-g" if what follows is a sha?
I feel like I've missed something as I find b) very surprising. (Consider giving someone the string $LATEST_VERSION_NUMBER-g$MALICIOUS_VERSION_SHA; I can't work out an exact exploit but it seems wrong to only process the SHA.)
I don’t like semantic versioning because it’s difficult to sort. E.g. 1.2 is more than 1.100, and that doesn’t even include fix versions.
Has there been a better proposal to semantic tags which makes organizing and sorting them easier?
What are the pros and cons of branches+merge-commits vs tags?
So instead of a "v4.11-rc7-87" tag you would have a "v4.11-rc7-87" branch and a merge commit that holds the meta info about that branch.
How do I pull something like LLVM 14.0.0 by tag?
Please don't prefix version tags with "v"...
The author suggest prepending v to a tag name for the sake of shell completion. This assumes that everyone will be interacting with git tags using a shell. I disagree that a v should be prepended for that reason.
> The commit that changed the version in source is the one to be tagged
I've never understood this practice of not immediately bumping the version in source after a release. We update the version in source to the next logical version (usually a patch bump with an alpha0 pre-release tag) immediately after tagging and publishing a release. This way you just need to look at the version in source to understand where you're at in a release process, and only a single commit has the full release version in source, which is also tagged as such. This doesn't seem to be a common pattern, so shat are the downsides of this approach? Am I missing something?