Additionally, gorelease should suggest a minor version increment if the go version increases either in the main module's go.mod or in a required module that provides a package transitively imported by a package in the main module.

The go version is kind of a dependency on the language itself. We should bump the minor version in the same circumstances as another dependency.

I recall there being some discussion about how go version changes we really breaking changes. What is the consensus on the stability of this type of change?

• go1.14 with go 1.13 will work fine because the go1.14 compiler knows about all previous releases.
• go1.13 with go 1.14 could be a breaking change since go1.13 does not know about binary literals.

You could make the same argument about any dependency though.

• I initially depend on example.com/strconv at v1.0.0.
• I upgrade example.com/strconv at v1.1.0 to call a newly introduced function ParseBinaryLiteral.
• A module that depends on me would be broken unless they also upgrade example.com/strconv to v1.1.0 (which MVS would do automatically).

Upgrading the go version is not a breaking change in that modules shouldn't have to change any of their own code in order to upgrade. It does require a newer version of Go though, which can't be done automatically with MVS.

That is fair, and I am not strictly advocating for it being a breaking change, just trying to ensure we agree it is not. I also dislike that the upgrade Go step is not as easy as MVS, because the failure modes mia not be clear to customers, but i guess that is a toolchain issue? For most cases it is pretty easy.

My one concern is some customers may not want to upgrade or not be able to, either because of bugs, uncertainty, or restrictive runtimes, like App Engine, that lock customers to a given release. For such cases where upgrade is not feasible, or at least trivial, does this change your calculus?

My one concern is some customers may not want to upgrade or not be able to, either because of bugs, uncertainty, or restrictive runtimes, like App Engine, that lock customers to a given release. For such cases where upgrade is not feasible, or at least trivial, does this change your calculus?

I think this makes it more important to encourage module authors to increment the minor version when updating the go version.

Using new features in a dependency (whether it's a regular module or the Go language or standard library) means your dependents also need to update. If they can't update their version of that dependency for some reason, it also means they can't update to new versions of your module.

I should have been more clear, I was (devil's) advocating for a major version bump, not patch or none.

I guess I was drawing the compatibility line as: if it compiled yesterday, I upgrade a minor or patch dependency, it should compile today. If anything breaks it is a breaking change, and would need a major version.

I think it is fair to exempt the compiler, but I am unclear if users understand/agree or the toolchain will notify them of what to do to resolve the issue.

Note: The toolchain warning looks like this:

[user@localhost test]$ GOROOT=../go1.12.17/ ../go1.12.17/bin/go run .
# test
./main.go:6:15: syntax error: unexpected b_1010_0110, expecting comma or )
note: module requires Go 1.15

My argument though is that updating a dependency to a new minor version may also require updating its dependencies to new minor versions. For normal module requirements, that happens automatically with MVS. For the go version, it can't happen automatically, but it's still needed.

Ok, I follow your logic: treat the go toolchain as another semver dependency, thus 1.13.6 -> 1.14.1 is a minor upgrade. Just to confirm, when go makes breaking changes, 1.18.4 -> 2.0.0, is that change breaking to a module, or because the compiler remembers it is fine?

Sorry for the pedantry, mostly wanted to make sure this discussion was had somewhere.

It's not clear that we will ever make a breaking change. If we do make a breaking change, it's not clear that we will change the major version of the Go release. See discussion at https://go.googlesource.com/proposal/+/refs/heads/master/design/28221-go2-transitions.md .

Hypothetically, if there ever is an incompatible change to the language, the compiler should still be compatible with code written for older versions of the language. This was the main reason the go directive in go.mod was introduced: the compiler can build different modules written for different versions of Go.

Change https://golang.org/cl/255880 mentions this issue: x/exp/cmd/gorelease: suggest a minor version increment if requirements increase