Git flow release branches and tags - with or without "v" prefix

Question

I have seen multiple contradicting definitions on various git flow related websites. Is there an official recommendation or single source of truth?

Branches: release-1.2.3 or release-v1.2.3

Tags: 1.2.3 or v1.2.3

Orientalize

See also #2006765 – Shari

Answer 1

Well, basically it is a matter of preference, but I prefer the version with the v, as Semver does it that way and I try to follow that specification as close as possible to get a sane versioning.

It also makes filtering for those Tags easier, as you can press v and then the TAB-key for autocompletion: This will list all the tags (and maybe a few branches), whereas there are several digits a tag could start with.

Edit: In 2019, Semver added a section to their FAQ, clarifying that the "v" prefix is "a common way to indicate a version number" (see "Is “v1.2.3” a semantic version?").

---

See also: Is there a standard naming convention for git tags?

Planetoid

Thanks, that makes sense. I think it is interesting to see that the Git Flow project itself does not use the v prefixes: github.com/nvie/gitflow For the reasons you and @VonC posted, I still prefer version tags that include the v prefix. – Orientalize

Semver has removed the prefixed v in version 2. – Delirious

See: github.com/mojombo/semver/blob/master/… – Pestalozzi

@Delirious @LeoTM - The document only states that v1.2.3 is not a semantic version. The question was about Git tags. In fact, the semver repo still uses v2.0.0 as a tag for version 2: github.com/mojombo/semver/releases/tag/v2.0.0 – Orientalize

semver 2.0 semver.org doesn't state anything about the tags needed to begin with a "v" prefix! – Scammony

You say Semver does it with the v, but your link to the SemVer definition makes no mention of 'v', and shows many examples without it. – Whirlwind

Since there's some debate on what Semver 2.0 says, let me quote it: '“v1.2.3” is not a semantic version. However, prefixing a semantic version with a “v” is a common way (in English) to indicate it is a version number. Abbreviating “version” as “v” is often seen with version control. Example: git tag v1.2.3 -m "Release version 1.2.3"' – Devon

The quoted part by @JakeStevens-Haas means that SemVer no longer "does it that way" as the answer stated, so the answer is claiming something that is no longer true. – Coalesce

Answer 2

Since v stands for version, tags are generally named vX.Y.Z, with X.Y.Z following Semantic Versioning 2.0.0.

This allows for branches X.Y.Z to co-exist with those tags, without having to deal with error message like "fatal: Ambiguous object name" (as in "Ambiguous Names with GIT?").

Note that the tags for Git itself have recently been "adapted" for a surprising reason: see "Code version change “rules”".

Grating

When people are using best practice like semver, then they probably use a system like Git Flow or something similar. That would prevent that clash of refs (branch eq tag name). Aside from that, what would hold one back from naming a branch vX.Y.Z then? That's not really that much of an argument :) – Adapt

semver 2.0 semver.org doesn't state anything about the tags needed to begin with a "v" prefix! – Scammony

@Scammony I agree. I only mentioned semver for the X.Y.Z policy. – Grating

One minor argument is that more people will get v1.2.3 than b1.2.3 :-) – Skep

Answer 3

https://semver.org/#is-v123-a-semantic-version

Is “v1.2.3” a semantic version? No, “v1.2.3” is not a semantic version. However, prefixing a semantic version with a “v” is a common way (in English) to indicate it is a version number. Abbreviating “version” as “v” is often seen with version control. Example: git tag v1.2.3 -m "Release version 1.2.3", in which case “v1.2.3” is a tag name and the semantic version is “1.2.3”.

Bik