3 ms·

Okay, here's a real world example. Three months ago, stretchr/testify was version 1.3 and supported Go 1.10. Yesterday, we tried to build some project, and sudd

Okay, here's a real world example. Three months ago, stretchr/testify was version 1.3 and supported Go 1.10. Yesterday, we tried to build some project, and suddenly tests don't run because, you see, now testify is version 1.6 and they support only Go 1.13 and up. That's a bloody breaking change, okay? And it happens all the time with Go packages: they're constantly in the process of dropping support for older Go versions without bumping major versions.

dullgiulio 6y ago
And is Go so hard to upgrade for your application? Go the language is really best in class when it comes to keeping backwards compatibility.
- Spivak 6y ago
  But this is still a breaking change though. If I build my app today I should be able to build it again tomorrow without any issue.
- Joker_vD 6y ago
  Well, in this particular case it was hard. The used version of one our internal libraries didn't support Go 1.13, so we bumped its version, and that required some more dependencies brought in and updated, and then it turned out that the container with Go 1.13 was misconfigured so it literally had no access to that internal library, at all (something with Gitlab deploy keys...), so in a hurry we tried to vendor this internal library wholesale, and then there were some problems with gomod-ed libs and those without go.mod, and some linters had to be explicitly told to skip the 'vendor' directory (wtf), and... And at this point, I just stopped digging down that rabbit hole and instead added TESTIFY := github.com/stretchr/testify and mkdir -p "$(GOPATH)/src/$(TESTIFY)" ; git clone --depth 1 --branch v1.3.0 https://$(TESTIFY).git "$(GOPATH)/src/$(TESTIFY)" before 'go install' in the build script, and ran it in the container with Go 1.10. This change took 5 minutes to make and worked without any problems. Isn't the one of the reasons we use semver in the first place so that after you do some small change to the current application you're working on, you don't suddenly find yourself having to update 2/3 of your the environment just to compile it?
grey-area 6y ago
That's a good example of the difficulties here. If they used go mod and didn't see it as a breaking change you'd be in the same situation. I think many people would debate whether this is breaking or not or deserves a major version - I think most people would say no if that was the only change. If they used go mod and did see this as a breaking change, they'd increment the major version and you'd never notice. The unfortunate consequence is most of their consumers would continue happily using a version 1.3 multiple major versions behind and missing critical security fixes (most projects backport fixes for say two major versions) - and they'd probably end up with users on a range of major versions from 1.x to 21.x if this is your definition of a significant breaking change. In theory under strong semver every single possible breaking change would be a new major version and every bit of software more than a few years old would be on version 945.5.1 - in practice, in the real world we never see that sort of versioning, and people use major versions for something very different (for significant changes in api surface (whether breaking or not), and sometimes for significant breaking changes). It's a signal rather than a hard objective rule. None of this is insurmountable of course, but it does need to be attended to. At present go mod seems to assume strong semver and the result would be IMO a proliferation of breaking changes and outdated software being used (as opposed to current Go which almost forces everyone to be on HEAD and to try to avoid breaking others).
- Joker_vD 6y ago
  Dropping a support for a language version is a breaking change. You literally can't compile the dependency itself. If that is not a breaking change by your definition, then nothing is. And I don't know if they use go mod or not because, as you probably know, Go 1.10 doesn't support go mod, it was started being introduced in Go 1.11. I don't argue for strict semver, you can never be sure if a supposedly minor change won't actually break things, sure, but some changes are guaranteed to break things. Why not at least mark them with the version bump?
  - curryst 6y ago
    Do they have an announced support policy for versions? If they have a policy that says they support the 3 most recent stable major versions, I wouldn't count deprecating support for a non-supported version of Go to be a breaking change. They aren't breaking anything because your version of Go is no longer supported on those versions. Whether you think that deprecating support for a language version (regardless of whether it continues to build with that version or not) requires a major version change is probably a matter of personal opinion. I would tend to say no, but I can see valid arguments for it (mainly because semver doesn't actually give us enough bits to communicate granular info). What would be ideal is if we had a means of communicating more information about releases of code and their relationship than semver provides. I.e. I can publish a repo and add some kind of "language-support.json" document that specifies I support the 3 latest major releases of Go, and have the package manager figure out whether my version of Go is supported. Other ideas for metadata would be the ability to add labels to releases, and have the option to filter/prioritize upgrades based on those. I would love if package managers supported labels as part of the metadata, and I could get a summary of all the labels between my current version and the new version. So on an upgrade, I could get a label diff for the package versions like "security:cve-1234 feature:oauth2-support bugfix:stale-kafka-messages". Those are cherry picked things that make nice labels, not everything makes sense in those messages. But sometimes it feels like we just do global updates and make sure everything builds, just to keep the tech debt low. I have no idea what actually changed in the package, and as long as it builds and tests pass I don't have to know. That's because we have so many dependencies, and it would take ages to read the release notes for all of the versions of all of the dependencies between our current version and the new one. Labels provide a means to communicate a succinct version of what changed; succinct enough for someone to read while they're waiting on tests to run.
harikb 6y ago
I think it unreasonable to expect “go mod” to support any compiler version other than what is officially supported for Go - latest Go major and one older version. You are right about your case, but your use case of continuing to use an old version of Go is not something they support.

dullgiulio 6y ago

And is Go so hard to upgrade for your application? Go the language is really best in class when it comes to keeping backwards compatibility.

Spivak 6y ago
But this is still a breaking change though. If I build my app today I should be able to build it again tomorrow without any issue.
Joker_vD 6y ago
Well, in this particular case it was hard. The used version of one our internal libraries didn't support Go 1.13, so we bumped its version, and that required some more dependencies brought in and updated, and then it turned out that the container with Go 1.13 was misconfigured so it literally had no access to that internal library, at all (something with Gitlab deploy keys...), so in a hurry we tried to vendor this internal library wholesale, and then there were some problems with gomod-ed libs and those without go.mod, and some linters had to be explicitly told to skip the 'vendor' directory (wtf), and... And at this point, I just stopped digging down that rabbit hole and instead added TESTIFY := github.com/stretchr/testify and mkdir -p "$(GOPATH)/src/$(TESTIFY)" ; git clone --depth 1 --branch v1.3.0 https://$(TESTIFY).git "$(GOPATH)/src/$(TESTIFY)" before 'go install' in the build script, and ran it in the container with Go 1.10. This change took 5 minutes to make and worked without any problems. Isn't the one of the reasons we use semver in the first place so that after you do some small change to the current application you're working on, you don't suddenly find yourself having to update 2/3 of your the environment just to compile it?

grey-area 6y ago

That's a good example of the difficulties here. If they used go mod and didn't see it as a breaking change you'd be in the same situation. I think many people would debate whether this is breaking or not or deserves a major version - I think most people would say no if that was the only change. If they used go mod and did see this as a breaking change, they'd increment the major version and you'd never notice. The unfortunate consequence is most of their consumers would continue happily using a version 1.3 multiple major versions behind and missing critical security fixes (most projects backport fixes for say two major versions) - and they'd probably end up with users on a range of major versions from 1.x to 21.x if this is your definition of a significant breaking change. In theory under strong semver every single possible breaking change would be a new major version and every bit of software more than a few years old would be on version 945.5.1 - in practice, in the real world we never see that sort of versioning, and people use major versions for something very different (for significant changes in api surface (whether breaking or not), and sometimes for significant breaking changes). It's a signal rather than a hard objective rule. None of this is insurmountable of course, but it does need to be attended to. At present go mod seems to assume strong semver and the result would be IMO a proliferation of breaking changes and outdated software being used (as opposed to current Go which almost forces everyone to be on HEAD and to try to avoid breaking others).

Joker_vD 6y ago
Dropping a support for a language version is a breaking change. You literally can't compile the dependency itself. If that is not a breaking change by your definition, then nothing is. And I don't know if they use go mod or not because, as you probably know, Go 1.10 doesn't support go mod, it was started being introduced in Go 1.11. I don't argue for strict semver, you can never be sure if a supposedly minor change won't actually break things, sure, but some changes are guaranteed to break things. Why not at least mark them with the version bump?
- curryst 6y ago
  Do they have an announced support policy for versions? If they have a policy that says they support the 3 most recent stable major versions, I wouldn't count deprecating support for a non-supported version of Go to be a breaking change. They aren't breaking anything because your version of Go is no longer supported on those versions. Whether you think that deprecating support for a language version (regardless of whether it continues to build with that version or not) requires a major version change is probably a matter of personal opinion. I would tend to say no, but I can see valid arguments for it (mainly because semver doesn't actually give us enough bits to communicate granular info). What would be ideal is if we had a means of communicating more information about releases of code and their relationship than semver provides. I.e. I can publish a repo and add some kind of "language-support.json" document that specifies I support the 3 latest major releases of Go, and have the package manager figure out whether my version of Go is supported. Other ideas for metadata would be the ability to add labels to releases, and have the option to filter/prioritize upgrades based on those. I would love if package managers supported labels as part of the metadata, and I could get a summary of all the labels between my current version and the new version. So on an upgrade, I could get a label diff for the package versions like "security:cve-1234 feature:oauth2-support bugfix:stale-kafka-messages". Those are cherry picked things that make nice labels, not everything makes sense in those messages. But sometimes it feels like we just do global updates and make sure everything builds, just to keep the tech debt low. I have no idea what actually changed in the package, and as long as it builds and tests pass I don't have to know. That's because we have so many dependencies, and it would take ages to read the release notes for all of the versions of all of the dependencies between our current version and the new one. Labels provide a means to communicate a succinct version of what changed; succinct enough for someone to read while they're waiting on tests to run.

harikb 6y ago

I think it unreasonable to expect “go mod” to support any compiler version other than what is officially supported for Go - latest Go major and one older version. You are right about your case, but your use case of continuing to use an old version of Go is not something they support.