Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: go.mod versioning is inconsistent #30146
v prefixing is just a stupid git tag convention, that is not used by everyone, since nothing git side actually parses or enforces this convention. And many software projects do not use it. And someday someone will add actual support for versions in git since pretty much everyone need it and pretty much everyone need to distinguish those from free-form tags, and lax conventions are not a good way to build robust tooling.
But, the original go.mod proposal decided to enshrine this idiotic needless prefix in its syntax, including in the json outputted by
But, go modules can not even use this convention consistently, we have now a Go object, that contains a something which is obviously a version, using a completely different syntax.
Please make up your mind and use regular syntax that does not require multiple levels of parser quirks
If you're going to make a proposal to change how modules work, I'd suggest refraining from using words like "stupid" and "idiotic", and sentences like "please make up your mind".
Can you back this up with any particular proposal or upstream plan to change git? Also note that Go supports many other source control managers, such as Mercurial and Subversion. So the specific features of Git aren't that important.
I'm also not sure I understand what the problem is with a
In particular, for large breaking changes like this one, you should open a proposal issue, detailing why the benefits of the proposed change greatly outweigh the downsides such as breaking backwards compatibility.
That's somewhat inconsistent with using a v prefix to mark versions, as v only exists as an example in a git man page (not even as something in the git code) and this git man page example, that a lot of projects do not apply, has spread all over the go module syntax.
Hi @nim-nim, I think you are making multiple points here, and I just wanted to add a comment in response to only some portions of what you have said.
When it comes to the
That said, I will share my personal understanding, which is in semver there is a distinction drawn between:
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).
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:
That certainly suggests to me that a leading
However, that FAQ is only on the semver
Setting aside for the moment what the best encoding might be, it seems reasonable to me that the
However, note that tags like
The result is recorded in the go.mod file as the following pseudo-version, which includes the date and commit hash:
That behavior is covered in more detail in the "Module Queries" section of the
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.
Regarding how that version information should be represented in the JSON returned by
and a bit later (under the
Separately, I think you might also be commenting on the new
Finally, I am just a member of the broader community myself, so please do not give too much weight to anything I have said here. ;-)
And the example you quote points directly to the git history of the git project… v before versions didn't exist before git implemented tags without bothering to distinguish versions, and Linus Torvalds just prefixed his version tags with v to workaround this deficiency (and then gave it as example in a git man page).
And, as an aside, there is nothing in git that makes sure a tag starting with v is a version (counter examples are easy to find), or that it is a semver if it is a version (the v-prefixed tags Linus uses are most definitely not semvers since they have weird things like -rcX postfixes)
So the whole house of cards just rests on a misinterpretation of a quick and dirty workaround by Linus Torvalds (I initially wrote hack but that would imply v prefixing was backed by some code git side. It definitely is not).
But, anyway, one should not need to write pages of scholarly text to justify syntax quirks,
(As a human, I find your scholarly explanations interesting and well written. As a
You haven't actually mentioned what about this is “inconsistent” — as far as I can see,
Module support has been available since Go 1.11 and there are many
That's because it indicates the version of the Go language in use, and versions of the Go language itself have never followed semantic versioning.
(If you believe that the language spec itself should be semantically versioned, that's a separate proposal to file — but, again, you'd need to show a compelling benefit based on more than just aesthetic preferences.)
@bcmills As much as I dislike resurrecting an angry thread, I wanted to ask if you thought it would be possible in the future for the go module solver to detect semantic versions that don't start with a
The reason I ask is that dep did understand semantic versions without a
@bvisness, if you have concrete examples of use of tags without the "v" prefix on existing Go projects, please open a new issue to discuss.
(Just to set expectations, though, I still think it's unlikely that we'll support them — what would happen if a repo had both a