As far as I understand it, there is a distinction drawn between: 1. a "semantic version" (where a leading "v" is not part of a "semantic version"), vs. 2. the mechanism for encoding a "semantic version" into a VCS tag (where a leading "v" is allowed)
In other words, under that interpretation, a leading "v" in a VCS tags is a common and allowed way to encode a semantic version into a VCS tag, although not a universal choice, and not required. However, I have also seen reasonable people disagree on that interpretation. One hint is the master branch for github.com/semver/semver contains this statement as part of an FAQ that was added a few years ago: -------------------- 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". -------------------- (From https://github.com/semver/semver/blob/master/semver.md) However, that FAQ is only on master as far as I am aware, and I have also seen reasonable people come to different conclusions even after reading that particular FAQ. Setting aside for the moment what the best encoding might be, it seems reasonable to me that the 'go' tool has made a choice about a canonical encoding of semantic versions into VCS tags. Finally, note that tags like "1.2.3" (without a "v") can still be used, but they will not be treated as semantic versions by the 'go' tool. Instead, "go get foo@1.2.3" (note no "v") and "go get foo@sometag" are treated as "module queries", and are often recorded as "pseudo-versions". There is a bit more about those two features of modules here: https://golang.org/cmd/go/#hdr-Module_queries https://golang.org/cmd/go/#hdr-Pseudo_versions Regards, thepudds On Monday, February 4, 2019 at 2:55:35 PM UTC-5, Ian Denhardt wrote: > > Also, on a more pragmatic level, what do you do if a repository has both > tags: is the "real" version "v2.0.0" or "2.0.0"? > > But I generally agree with the other arguments; machines should be > opinionated about the color of the shed, so humans can argue about > things that actually matter (see also gofmt). > > -Ian > > Quoting gud...@gmail.com <javascript:> (2019-02-04 13:24:55) > > If you start with two options you open up a flood of endless > > > > discussions about why just these two and not that other > > > > too. > > > > � > > No, it won't. Current version of semver convention (which is 2.0.0 > ATM > > and not 1.0.0)� says (as I mentioned) that any prefix violates > (mildly > > though) semver. > > And they mentioned explicitly only "v" prefix. No "r", no any other > > ridiculous ones since it's semver, not semrelease or semútgáfa. > > Other than that is just a faulty generalization and shouldn't be used > > against this point. > > I actually had nothing against� this particular prefix. > > It just shouldn't be the only option since semver itself doesn't have > > requirements on tagging notation (at least anymore) and even states > > against that. > > > > And the v prefix is pretty common > > > > Yep, and that's as common as no-prefix format. > > > > And retagging a "3.1.4" as "v3.1.4" is dead simple. > > > > Also changing go-semver standard to support non-prefixed tags without > > losing any backward compatibility. > > Current standard which meant to be implemented currently not > > implementing semver as it is. > > On Monday, February 4, 2019 at 11:31:58 AM UTC+3, Volker Dobler > wrote: > > > > Well, it is good to have exactly one valid format. > > With two options like "vN.M.L" and "N.M.L" confusion starts > > to spread and why not allow a capital "V" too and a "ú" too > > for "útgáfa" and "r" for "release" should be allowed too. > > If you start with two options you open up a flood of endless > > discussions about why just these two and not that other > > too. > > So the whole question is "why v.N.M.M and not N.M.L ?" > > This might be a question of taste and thus unanswerable. > > I personally think the v prefix makes it clear it is a version tag. > > Even Semver 1.0.0 suggested to prefix the version number > > with v in the VCS. > > And the v prefix is pretty common: Docker, Kubernetes, CoreOS. > > And retagging a "3.1.4" as "v3.1.4" is dead simple. > > In summary. There is one format and that one is v<Semver>; > > it is a standard and standards are to be implemented. > > V.� > > On Monday, 4 February 2019 07:52:09 UTC+1, Maxim S wrote: > > > > Now go mod requires to have prefix "v" for it's tag in VCS and it's > > mandatory so you can't use tags in form of "A.B.C" in your workflow. > > But this limitation has little to zero reason to exist so why is it > > strict requirement? Why not to allow use both "vA.B.C" and "A.B.C" > > tags?� Who are using "A.B.C" tags for anything but version? > > It can be done without modifying current .mod files by just ignoring > > "v" prefix during repository search. > > Many teams use prefix-less tags for versions (both for Go before > > modules and non-Go projects). Not to mention that it's [1]not a valid > > semver� (but very common though) and thus requirement even less > > understandable. > > > > -- > > You received this message because you are subscribed to the Google > > Groups "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, > send > > an email to [2]golang-nuts...@googlegroups.com <javascript:>. > > For more options, visit [3]https://groups.google.com/d/optout. > > > > Verweise > > > > 1. > https://github.com/semver/semver/blob/master/semver.md#is-v123-a-semantic-version > > > 2. mailto:golang-nuts+unsubscr...@googlegroups.com <javascript:> > > 3. https://groups.google.com/d/optout > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
