3 ms·

Go 1 compatibility promise is not about std lib API at large: a set of core APIs, the "standard packages" of the Go library. Also none of the std libs are vers

• ollien 5y ago
  From that page: > Go 1 defines two things: first, the specification of the language; and second, the specification of a set of core APIs, the "standard packages" of the Go library. ... > The APIs may grow, acquiring new packages and features, but not in a way that breaks existing Go 1 code. So yes, it does apply to the standard library, AFAICT
  • Thaxll 5y ago
    I don't undertsand it that way, it's not all the std APIs, just some of them ( the core ones ).
    • Twirrim 5y ago
      Where is this list defined? If it's not defined specifically, it would seem the intent is the stdlib.
• TheDong 5y ago
  > none of the std libs are versioned, and I don't see any time soon a v2 for it. There is one precedent: the syscall package (https://golang.org/s/go1.4-syscall https://golang.org/s/go1.4-syscall) It was deprecated and replaced with the versioned 'golang.org/x/sys/unix' package instead. The reason the syscall package was changed to an x package was because the x package could be versioned better, and because the stdlib package had to make breaking changes. I'm more or less just asking why we don't do the same thing for tls, http, and any other packages that, like syscall, have issues that cannot be fixed in a backwards compatible way. It seems like we've ended up making inconsistent decisions here, which ultimately lead to go programs breaking during go compiler upgrades... which is a thing that isn't supposed to happen.