4 ms·

I'm excited to see this. I would hope to see someone from the Go community get involved in the maintainer group, though. Russ Cox's philosophy on versioning is

I'm excited to see this. I would hope to see someone from the Go community get involved in the maintainer group, though. Russ Cox's philosophy on versioning is now baked into the Go language pretty deeply, and it's (at least partly) motivated by problems with semver, real or perceived: > Where I think semver falls short is the idea that “having to bump major versions” is a step that will make you “think through the impact of your changes and evaluate the cost/benefit ratio involved.” Quite the opposite: it’s far too easy to read semver as implying that as long as you increment the major version when you make an incompatible change, everything else will work out. The example shows that this is not the case. (from https://research.swtch.com/vgo-import https://research.swtch.com/vgo-import, one of the treatises on go versioning) Despite this criticism, Go is sort of still using semver, at least as a way to compare string version identifiers. I think it's fair to say that Go users form a significant community using semantic versioning. It would be a mistake to leave them out of RFC discussions on the topic.

steveklabnik 8y ago
I didn't previously reach out to anyone from Go specifically because they do not really use SemVer. As a group, we're open to including others than this initial roster, but didn't think it would be particularly relevant to their interest. If that's incorrect, someone please get in touch!
- spenczar5 8y ago
  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!
jrochkind1 8y ago
Ironically, much of the rest of this thread is people saying they refuse to use or don't like semver _because_ they want to be introducing backwards-breaking changes without incrementing the major version number. So, while there may be some projects that introduce backwards-breaking changes and increment major versions willy-nilly, I think actual observed developer behavior does not justify Russ Cox's supposition that semver does not serve as a disincentive to introduce breaking changes generally. People are complaining about semver _because_ they find it a disincentive, and don't want it there telling them they can't release backwards breaks without a major version bump they don't want to do :) Of course, you can lead a horse to water... Perhaps the semver docs should make it clear that frequent backwards-breaking releases _still are likely_ to create developer pain even if you increment the major version release number, I dunno.
anth_anm 8y ago
> Quite the opposite: it’s far too easy to read semver as implying that as long as you increment the major version when you make an incompatible change, everything else will work out. The example shows that this is not the case. and if you do that too often then you either end up with a bunch of maintenance on old versions or a use base that hates you. Isn't that the real disincentive?

steveklabnik 8y ago

I didn't previously reach out to anyone from Go specifically because they do not really use SemVer. As a group, we're open to including others than this initial roster, but didn't think it would be particularly relevant to their interest. If that's incorrect, someone please get in touch!

spenczar5 8y ago
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!

jrochkind1 8y ago

Ironically, much of the rest of this thread is people saying they refuse to use or don't like semver _because_ they want to be introducing backwards-breaking changes without incrementing the major version number. So, while there may be some projects that introduce backwards-breaking changes and increment major versions willy-nilly, I think actual observed developer behavior does not justify Russ Cox's supposition that semver does not serve as a disincentive to introduce breaking changes generally. People are complaining about semver _because_ they find it a disincentive, and don't want it there telling them they can't release backwards breaks without a major version bump they don't want to do :) Of course, you can lead a horse to water... Perhaps the semver docs should make it clear that frequent backwards-breaking releases _still are likely_ to create developer pain even if you increment the major version release number, I dunno.

anth_anm 8y ago

> Quite the opposite: it’s far too easy to read semver as implying that as long as you increment the major version when you make an incompatible change, everything else will work out. The example shows that this is not the case. and if you do that too often then you either end up with a bunch of maintenance on old versions or a use base that hates you. Isn't that the real disincentive?