4 ms·

> as a consequence of our forward compatibility work, Go 1.21 will not attempt to compile code that declares go 1.22 or later. We included a special case with t

> as a consequence of our forward compatibility work, Go 1.21 will not attempt to compile code that declares go 1.22 or later. We included a special case with the same effect in the point releases Go 1.20.8 and Go 1.19.13, so when Go 1.22 is released, code written depending on the new semantics will never be compiled with the old semantics, unless people are using very old, unsupported Go versions How does this work? If I pull in a package that decided to pin 1.22 (as they should) and I compile with 1.18, would it compile or error that I need to use the 1.22 compiler?

packetlost 3y ago
Yes.
jchw 3y ago
Interestingly, though, if you use Go 1.21 and a module declares a later version of Go, the default behavior is actually to go fetch a newer toolchain and use it instead[1]. It's a pretty cool feature, but I am a bit on the fence due to the fact that it is surprising and phones home to Google-controlled servers to fetch the binaries. That and the module proxy are for sure two of the most conflicting features in Go and I'd feel a lot better about them if Go was controlled by a foundation that Google merely had a stake in. Alas. edit: Actually, though, I just realized what I am talking about is different than what you and your quote is talking about, which is what happens when you have a dependency that declares a different version, not the current module. Oops. [1]: https://go.dev/blog/toolchain https://go.dev/blog/toolchain
tedunangst 3y ago
You should get a compile error. But your code, when compiled with go 1.22, will still have go 1.18 semantics.
yankput 3y ago
They way I understand this, with go 1.18, 1.22 module as a dependency will compile and produce errorneous logic (!!) if it depends on this feature Thus it will be actively dangerous using go 1.18. I understand it like that. With go 1.19, you will get a compiler error. But as go is not fixing security bugs in old releases and std library, I think it is dangerous to use them anyway.
- jerf 3y ago
  "But as go is not fixing security bugs in old releases and std library, I think it is dangerous to use them anyway." A bit of a harsh way to phrase that. In my experience, the backwards compatibility promises have been very good, and the way you stay up-to-date with security fixes and bugs in the standard library is to upgrade Go. I know that may strike terror in the hearts of developers used to the nightmare that major version upgrades can be in other languages, where a major version upgrade gets a multi-week task added into the task tracker, but it's completely routine for me to upgrade across Go major versions just to get some particular fix or to play with a new feature. I expect it to be a roughly five minute task, routinely. The only thing that has bitten me about it is arguably not even Go's fault, which is its continuing advances in TLS security and the increasing fussiness with which it treats things connecting with old-style certificates. I can't even necessarily disagree... I would also like to upgrade them but while it's my server, the clients connecting to it are using certs that are not mine and it's out of my control.
  - yankput 3y ago
    > A bit of a harsh way to phrase that. In my experience, the backwards compatibility promises have been very good, and the way you stay up-to-date with security fixes and bugs in the standard library is to upgrade Go. I don’t think we disagree? There is no reason to use old version of go. I speak about grandparent comment who wanted to still run go1.18. It is not a good idea to still run go1.18, as it doesn’t get security updates.
icholy 3y ago
They did something sneaky. In go 1.21, they changed the version number format in the `go.mod` files. So trying to build with go 1.18 will result in: go: errors parsing go.mod: go.mod:3: invalid go version '1.21.0': must match format 1.23 However, this will only happen if you use the `go mod init` to create your module. If you manually specify `go 1.21` in your `go.mod`, it will build without complaining.

packetlost 3y ago

Yes.

jchw 3y ago

Interestingly, though, if you use Go 1.21 and a module declares a later version of Go, the default behavior is actually to go fetch a newer toolchain and use it instead[1]. It's a pretty cool feature, but I am a bit on the fence due to the fact that it is surprising and phones home to Google-controlled servers to fetch the binaries. That and the module proxy are for sure two of the most conflicting features in Go and I'd feel a lot better about them if Go was controlled by a foundation that Google merely had a stake in. Alas. edit: Actually, though, I just realized what I am talking about is different than what you and your quote is talking about, which is what happens when you have a dependency that declares a different version, not the current module. Oops. [1]: https://go.dev/blog/toolchain https://go.dev/blog/toolchain

tedunangst 3y ago

You should get a compile error. But your code, when compiled with go 1.22, will still have go 1.18 semantics.

yankput 3y ago

They way I understand this, with go 1.18, 1.22 module as a dependency will compile and produce errorneous logic (!!) if it depends on this feature Thus it will be actively dangerous using go 1.18. I understand it like that. With go 1.19, you will get a compiler error. But as go is not fixing security bugs in old releases and std library, I think it is dangerous to use them anyway.

jerf 3y ago
"But as go is not fixing security bugs in old releases and std library, I think it is dangerous to use them anyway." A bit of a harsh way to phrase that. In my experience, the backwards compatibility promises have been very good, and the way you stay up-to-date with security fixes and bugs in the standard library is to upgrade Go. I know that may strike terror in the hearts of developers used to the nightmare that major version upgrades can be in other languages, where a major version upgrade gets a multi-week task added into the task tracker, but it's completely routine for me to upgrade across Go major versions just to get some particular fix or to play with a new feature. I expect it to be a roughly five minute task, routinely. The only thing that has bitten me about it is arguably not even Go's fault, which is its continuing advances in TLS security and the increasing fussiness with which it treats things connecting with old-style certificates. I can't even necessarily disagree... I would also like to upgrade them but while it's my server, the clients connecting to it are using certs that are not mine and it's out of my control.
- yankput 3y ago
  > A bit of a harsh way to phrase that. In my experience, the backwards compatibility promises have been very good, and the way you stay up-to-date with security fixes and bugs in the standard library is to upgrade Go. I don’t think we disagree? There is no reason to use old version of go. I speak about grandparent comment who wanted to still run go1.18. It is not a good idea to still run go1.18, as it doesn’t get security updates.

icholy 3y ago

They did something sneaky. In go 1.21, they changed the version number format in the `go.mod` files. So trying to build with go 1.18 will result in: go: errors parsing go.mod: go.mod:3: invalid go version '1.21.0': must match format 1.23 However, this will only happen if you use the `go mod init` to create your module. If you manually specify `go 1.21` in your `go.mod`, it will build without complaining.