To give a quick concrete example for the point below about still being able to make use of an existing tag that does not have a leading "v"...
If you do the following from within a module (note no "v" in "0.0.3"): $ go get github.com/jondot/groundcontrol@0.0.3 The result is recorded in the go.mod file as the following pseudo-version, which includes the date and commit hash: github.com/jondot/groundcontrol v0.0.0-20130702202810-bf0b23022af7 This behavior is covered in more detail here: https://golang.org/cmd/go/#hdr-Module_queries All that said, a module should still be tagged in VCS with a leading "v" when released in order for the 'go' tool to be able to properly interpret the tag as a semantic version. Regards, thepudds On Monday, February 4, 2019 at 5:39:25 PM UTC-5, thepud...@gmail.com wrote: > > 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 (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. >> > 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 >> > 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.
