3 ms·

The language implements semver directly in the Go language source: https://github.com/golang/go/blob/47d5a4433513c3870a9994b50ed4fa2af628c742/src/cmd/go/interna

The language implements semver directly in the Go language source: https://github.com/golang/go/blob/47d5a4433513c3870a9994b50ed4fa2af628c742/src/cmd/go/internal/semver/semver.go https://github.com/golang/go/blob/47d5a4433513c3870a9994b50e... This is used to resolve module loading, according to this logic: https://github.com/golang/go/blob/aab0b704d88b7dad10c767ad941619d59887203c/src/cmd/go/internal/modload/query.go#L17-L35 https://github.com/golang/go/blob/aab0b704d88b7dad10c767ad94...

steveklabnik 8y ago
Thanks for the citations! Reading this, it's semver-ish for sure; that said, the "ish" is exactly why we're doing this. I'll try to figure out how to get in touch with someone.
- spenczar5 8y ago
  Excellent, thank you! I would recommend a brief post on https://groups.google.com/forum/#!forum/golang-dev; https://groups.google.com/forum/#!forum/golang-dev; that's the main hub for people who work on Go itself.
- Queue29 8y ago
  Can you clarify why what Go is doing is only semver-"ish"? What would you have them do differently to be described as semver compliant without the -"ish"?
  - steveklabnik 8y ago
    https://github.com/golang/go/blob/47d5a4433513c3870a9994b50ed4fa2af628c742/src/cmd/go/internal/semver/semver.go#L19-L22 https://github.com/golang/go/blob/47d5a4433513c3870a9994b50e... are the two that they identified. Both of these things are not deal breakers; some semver implementations do allow the prefix "v" (though none require, and some don't allow it too), and their other modification to version numbers is sort of what is done in some parts of the other implementations do. And as I said elsewhere, the matchers aren't part of today's spec, so it feels weird to disqualify them based on a sparse implementation. My real point is that because the spec is incomplete, many of these kinds of questions cannot be answered, even within the big implementations. So I'm saying "ish" to hedge. Given the anti-SemVer tone throughout the vgo discussion, I thought they had gotten further away from the mainstream than they actually ended up, which is my mistake.
    - puddums 8y ago
      I think the initial vgo discussion and versioned Go modules proposal effectively said "developers expect semver; semver is helpful; Go is officially adopting and requiring semver". At the same time, I think there was also some discussion around "semver alone is not a complete answer". I can see how some of that might have been read as anti-semver, though I suspect that was not the intent. In any event, it is exciting to see more energy going into the semver spec!
- puddums 8y ago
  Hi Steve, I've looked at this relatively carefully, and I believe that Go does 100% follow the semver spec (modulo any bugs in the implementation). However, while that happens to be my personal belief, I am not any type of world-class semver expert, nor am a semver maintainer, and hence always happy to learn more (especially from, say, an actual semver maintainer such as yourself ;-) I think you are saying "-ish" in your comment above at least partly based the two chunks of linked code above, including this comment there: // This package follows Semantic Versioning 2.0.0 (see semver.org) // with two exceptions. First, it requires the "v" prefix. Second, it recognizes // vMAJOR and vMAJOR.MINOR (with no prerelease or build suffixes) // as shorthands for vMAJOR.0.0 and vMAJOR.MINOR.0. It is true that Go treats the leading "v" as a requirement for VCS tags to be recognized as encoding a semantic version. That said, as far as I am aware, requiring the "v" prefix for VCS tags is allowed by the semver spec, and it might be possible to draw a distinction between a semver version (which does not include a "v") vs. how a given semver version is encoded into a VCS tag (where an encoding is allowed to include a "v", as far as I am aware). For example, there is an FAQ that was added a few years ago to 'master' at github.com/semver/semver that seemed to address this: 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".[1] I am also aware that a leading "v" vs. no leading "v" for VCS tags can trigger some impassioned debate, so I might regret posting this comment. ;-) Regarding the second piece from that comment above -- that particular Go package does have the ability to parse something like "v1" or "v1.2" (without the three integers required by semver). However, the result is not interpreted as a valid semver version by the overall 'go' tool. For example, a VCS tag such as "v1.2" that the 'go' tool finds on a git repository will _not_ be interpreted as a semantic version (because it does not have the required three integers). However, being able to parse something like "v1" or "v1.2" is used for example as part of a version query mechanism. For example, you can do something like "go get foo@v1.2" as a way of asking "please give me the highest available release version in >= v1.2.0 and < v2.0.0". In other words, it is a short-hand for a particular type of version query, which I would guess would not be in violation of the current semver 2.0 spec? If interested, there is some more information about that query mechanism (which is called a "module query") in the Go doc[2]. Finally, here is a snippet from the Go doc[3] stating semver is used (and there is a link to https://semver.org https://semver.org in that section as well): The go command requires that modules use semantic versions and expects that the versions accurately describe compatibility I wouldn't be shocked if you have a different take on some or all of what I said above, but wanted to at least share my personal understanding... [1] https://github.com/semver/semver/blob/master/semver.md https://github.com/semver/semver/blob/master/semver.md [2] https://golang.org/cmd/go/#hdr-Module_queries https://golang.org/cmd/go/#hdr-Module_queries [3] https://golang.org/cmd/go/#hdr-Module_compatibility_and_semantic_versioning https://golang.org/cmd/go/#hdr-Module_compatibility_and_sema...
mohamedattahri 8y ago
Makes me wonder why this gem is buried under /internal and not exposed publicly. I could have used it in a couple of projects.

steveklabnik 8y ago

Thanks for the citations! Reading this, it's semver-ish for sure; that said, the "ish" is exactly why we're doing this. I'll try to figure out how to get in touch with someone.

spenczar5 8y ago
Excellent, thank you! I would recommend a brief post on https://groups.google.com/forum/#!forum/golang-dev; https://groups.google.com/forum/#!forum/golang-dev; that's the main hub for people who work on Go itself.
Queue29 8y ago
Can you clarify why what Go is doing is only semver-"ish"? What would you have them do differently to be described as semver compliant without the -"ish"?
- steveklabnik 8y ago
  https://github.com/golang/go/blob/47d5a4433513c3870a9994b50ed4fa2af628c742/src/cmd/go/internal/semver/semver.go#L19-L22 https://github.com/golang/go/blob/47d5a4433513c3870a9994b50e... are the two that they identified. Both of these things are not deal breakers; some semver implementations do allow the prefix "v" (though none require, and some don't allow it too), and their other modification to version numbers is sort of what is done in some parts of the other implementations do. And as I said elsewhere, the matchers aren't part of today's spec, so it feels weird to disqualify them based on a sparse implementation. My real point is that because the spec is incomplete, many of these kinds of questions cannot be answered, even within the big implementations. So I'm saying "ish" to hedge. Given the anti-SemVer tone throughout the vgo discussion, I thought they had gotten further away from the mainstream than they actually ended up, which is my mistake.
  - puddums 8y ago
    I think the initial vgo discussion and versioned Go modules proposal effectively said "developers expect semver; semver is helpful; Go is officially adopting and requiring semver". At the same time, I think there was also some discussion around "semver alone is not a complete answer". I can see how some of that might have been read as anti-semver, though I suspect that was not the intent. In any event, it is exciting to see more energy going into the semver spec!
puddums 8y ago
Hi Steve, I've looked at this relatively carefully, and I believe that Go does 100% follow the semver spec (modulo any bugs in the implementation). However, while that happens to be my personal belief, I am not any type of world-class semver expert, nor am a semver maintainer, and hence always happy to learn more (especially from, say, an actual semver maintainer such as yourself ;-) I think you are saying "-ish" in your comment above at least partly based the two chunks of linked code above, including this comment there: // This package follows Semantic Versioning 2.0.0 (see semver.org) // with two exceptions. First, it requires the "v" prefix. Second, it recognizes // vMAJOR and vMAJOR.MINOR (with no prerelease or build suffixes) // as shorthands for vMAJOR.0.0 and vMAJOR.MINOR.0. It is true that Go treats the leading "v" as a requirement for VCS tags to be recognized as encoding a semantic version. That said, as far as I am aware, requiring the "v" prefix for VCS tags is allowed by the semver spec, and it might be possible to draw a distinction between a semver version (which does not include a "v") vs. how a given semver version is encoded into a VCS tag (where an encoding is allowed to include a "v", as far as I am aware). For example, there is an FAQ that was added a few years ago to 'master' at github.com/semver/semver that seemed to address this: 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".[1] I am also aware that a leading "v" vs. no leading "v" for VCS tags can trigger some impassioned debate, so I might regret posting this comment. ;-) Regarding the second piece from that comment above -- that particular Go package does have the ability to parse something like "v1" or "v1.2" (without the three integers required by semver). However, the result is not interpreted as a valid semver version by the overall 'go' tool. For example, a VCS tag such as "v1.2" that the 'go' tool finds on a git repository will _not_ be interpreted as a semantic version (because it does not have the required three integers). However, being able to parse something like "v1" or "v1.2" is used for example as part of a version query mechanism. For example, you can do something like "go get foo@v1.2" as a way of asking "please give me the highest available release version in >= v1.2.0 and < v2.0.0". In other words, it is a short-hand for a particular type of version query, which I would guess would not be in violation of the current semver 2.0 spec? If interested, there is some more information about that query mechanism (which is called a "module query") in the Go doc[2]. Finally, here is a snippet from the Go doc[3] stating semver is used (and there is a link to https://semver.org https://semver.org in that section as well): The go command requires that modules use semantic versions and expects that the versions accurately describe compatibility I wouldn't be shocked if you have a different take on some or all of what I said above, but wanted to at least share my personal understanding... [1] https://github.com/semver/semver/blob/master/semver.md https://github.com/semver/semver/blob/master/semver.md [2] https://golang.org/cmd/go/#hdr-Module_queries https://golang.org/cmd/go/#hdr-Module_queries [3] https://golang.org/cmd/go/#hdr-Module_compatibility_and_semantic_versioning https://golang.org/cmd/go/#hdr-Module_compatibility_and_sema...

mohamedattahri 8y ago

Makes me wonder why this gem is buried under /internal and not exposed publicly. I could have used it in a couple of projects.