6 ms·

Well, that's clearly not the way Go operates. Go makes incompatible changes between minor releases; they just don't break type signatures. For example, debug/pe

Well, that's clearly not the way Go operates. Go makes incompatible changes between minor releases; they just don't break type signatures. For example, debug/pe ImportedLibraries(), which is supposed to return all the libraries that a module imports, was stubbed out to return "nil, nil" in a minor release [1]. This is clearly an incompatible change, but as it didn't cause code to fail to compile the Go team deemed it semver compatible. Edit: Apparently this is wrong! See replies below. [1]: https://fasterthanli.me/articles/abstracting-away-correctness https://fasterthanli.me/articles/abstracting-away-correctnes...

philosopher1234 5y ago
I think taking a highly abstract definition of backcompat is not useful. We need a practical definition of back compat. If there are no (or effectively no) downstream consequences of a change, it is clearly backcompat. If there are some downstream consequences, you get into judgment call territory, but it still may be worth it. We cannot create a perfect universal rule here, and Amos is a fool for holding that standard so rigidly.
pipe_connector 5y ago
It's worth noting that the author of that article was mistaken, there was likely some other issue with their software than what they described here. ImportedLibraries() in the pe package has never done anything other than returned nil, nil. This wasn't changed in a minor release. You can browse the source history here: https://github.com/golang/go/blame/master/src/debug/pe/file.go#L439 https://github.com/golang/go/blame/master/src/debug/pe/file....
slrz 5y ago
For example, debug/pe ImportedLibraries(), which is supposed to return all the libraries that a module imports, was stubbed out to return "nil, nil" in a minor release [1] I just looked at the Git history and this is plain false. It already looked that way when the big source tree move (src/pkg/ -> src/) was done in 2014. Tracing it back further (to before Go 1.0 times, when there wasn't even a builtin error interface yet and the function returned os.Error), ImportedLibraries was *never* implemented in debug/pe.
TheDong 5y ago
You're not wrong with your point, even if your example is. Go has made many breaking changes that still kept compiling, and compiling seems to be the thing they care about the most. Cribbing from a previous comment I've made... https://news.ycombinator.com/item?id=29763324 https://news.ycombinator.com/item?id=29763324 1. go 1.9 adding monotonic clock readings in a breaking way, i.e. this program changed output from 1.8 to 1.9: https://go.dev/play/p/Mi6cGCPd0rS https://go.dev/play/p/Mi6cGCPd0rS 2. net/http started defaulting to http/2 for the same methods, an obviously breaking change 3. go1.17 switched to silently truncating a lot of query strings https://go.dev/play/p/azODBvkb-zK https://go.dev/play/p/azODBvkb-zK 4. Check out 'PreferServerCipherSuites' on tls.Config. https://pkg.go.dev/crypto/tls#Config https://pkg.go.dev/crypto/tls#Config ; of course that was a breaking change. There's a few other things like this littered throughout the go stdlib, and I've personally hit far more breaking changes in Go's stdlib than the "go 1 compatibility promise" would have you expect.
- pcwalton 5y ago
  Thanks, I knew I had seen other examples other than the one I cited but had forgotten what they were.
- Mawr 5y ago
  > go 1.9 adding monotonic clock readings in a breaking way, i.e. this program changed output from 1.8 to 1.9: https://go.dev/play/p/Mi6cGCPd0rS https://go.dev/play/p/Mi6cGCPd0rS That's not a breaking change, if you were comparing Times with just "==" before 1.9, your program was broken as well: From the 1.8 source [1]: // Equal reports whether t and u represent the same time instant. // Two times can be equal even if they are in different locations. // For example, 6:00 +0200 CEST and 4:00 UTC are Equal. // Do not use == with Time values. func (t Time) Equal(u Time) bool { return t.sec == u.sec && t.nsec == u.nsec } [1]: https://cs.opensource.google/go/go/+/refs/tags/go1.8:src/time/time.go;l=75 https://cs.opensource.google/go/go/+/refs/tags/go1.8:src/tim...
  - TheDong 5y ago
    It was not until go1.8 that they added the warning to not use '=='. In go 1.7, it simply told you that == vs Equal had different semantics, see https://cs.opensource.google/go/go/+/refs/tags/go1.7:src/time/time.go;l=67-71 https://cs.opensource.google/go/go/+/refs/tags/go1.7:src/tim... There are many cases where you know that your times are in the same timezone, or you don't mind different timezones comparing as different, and so '==' used to work correctly quite often. My program was clearly not broken in 1.7, when I followed the documentation "Equal ignores location, == uses location", and things worked well. My program became counter to their documentation in 1.8. My program broke in 1.9. I don't see how that is not a breaking change.

philosopher1234 5y ago

I think taking a highly abstract definition of backcompat is not useful. We need a practical definition of back compat. If there are no (or effectively no) downstream consequences of a change, it is clearly backcompat. If there are some downstream consequences, you get into judgment call territory, but it still may be worth it. We cannot create a perfect universal rule here, and Amos is a fool for holding that standard so rigidly.

pipe_connector 5y ago

It's worth noting that the author of that article was mistaken, there was likely some other issue with their software than what they described here. ImportedLibraries() in the pe package has never done anything other than returned nil, nil. This wasn't changed in a minor release. You can browse the source history here: https://github.com/golang/go/blame/master/src/debug/pe/file.go#L439 https://github.com/golang/go/blame/master/src/debug/pe/file....

slrz 5y ago

For example, debug/pe ImportedLibraries(), which is supposed to return all the libraries that a module imports, was stubbed out to return "nil, nil" in a minor release [1] I just looked at the Git history and this is plain false. It already looked that way when the big source tree move (src/pkg/ -> src/) was done in 2014. Tracing it back further (to before Go 1.0 times, when there wasn't even a builtin error interface yet and the function returned os.Error), ImportedLibraries was *never* implemented in debug/pe.

TheDong 5y ago

You're not wrong with your point, even if your example is. Go has made many breaking changes that still kept compiling, and compiling seems to be the thing they care about the most. Cribbing from a previous comment I've made... https://news.ycombinator.com/item?id=29763324 https://news.ycombinator.com/item?id=29763324 1. go 1.9 adding monotonic clock readings in a breaking way, i.e. this program changed output from 1.8 to 1.9: https://go.dev/play/p/Mi6cGCPd0rS https://go.dev/play/p/Mi6cGCPd0rS 2. net/http started defaulting to http/2 for the same methods, an obviously breaking change 3. go1.17 switched to silently truncating a lot of query strings https://go.dev/play/p/azODBvkb-zK https://go.dev/play/p/azODBvkb-zK 4. Check out 'PreferServerCipherSuites' on tls.Config. https://pkg.go.dev/crypto/tls#Config https://pkg.go.dev/crypto/tls#Config ; of course that was a breaking change. There's a few other things like this littered throughout the go stdlib, and I've personally hit far more breaking changes in Go's stdlib than the "go 1 compatibility promise" would have you expect.

pcwalton 5y ago
Thanks, I knew I had seen other examples other than the one I cited but had forgotten what they were.
Mawr 5y ago
> go 1.9 adding monotonic clock readings in a breaking way, i.e. this program changed output from 1.8 to 1.9: https://go.dev/play/p/Mi6cGCPd0rS https://go.dev/play/p/Mi6cGCPd0rS That's not a breaking change, if you were comparing Times with just "==" before 1.9, your program was broken as well: From the 1.8 source [1]: // Equal reports whether t and u represent the same time instant. // Two times can be equal even if they are in different locations. // For example, 6:00 +0200 CEST and 4:00 UTC are Equal. // Do not use == with Time values. func (t Time) Equal(u Time) bool { return t.sec == u.sec && t.nsec == u.nsec } [1]: https://cs.opensource.google/go/go/+/refs/tags/go1.8:src/time/time.go;l=75 https://cs.opensource.google/go/go/+/refs/tags/go1.8:src/tim...
- TheDong 5y ago
  It was not until go1.8 that they added the warning to not use '=='. In go 1.7, it simply told you that == vs Equal had different semantics, see https://cs.opensource.google/go/go/+/refs/tags/go1.7:src/time/time.go;l=67-71 https://cs.opensource.google/go/go/+/refs/tags/go1.7:src/tim... There are many cases where you know that your times are in the same timezone, or you don't mind different timezones comparing as different, and so '==' used to work correctly quite often. My program was clearly not broken in 1.7, when I followed the documentation "Equal ignores location, == uses location", and things worked well. My program became counter to their documentation in 1.8. My program broke in 1.9. I don't see how that is not a breaking change.