3 ms·

I was just criticizing the publishing skills of some people... The problem itself is unfortunate and I am personally not a huge fan of the "no API changes" phil

by tux21b 13y ago

I was just criticizing the publishing skills of some people... The problem itself is unfortunate and I am personally not a huge fan of the "no API changes" philosophy participated by the Go team. I can understand the reasons behind it, but it's still hard to read several CLs per day that are abandoned or done differently (in a non-optimal way) because of this contract.

enneff 13y ago
It's much better for the core team to compromise a little than force everyone to update their code all the time. In particular, small semantic changes that can't be caught statically will just break people's code with no warning whatsoever. That's bad.
- bluehex 13y ago
  The end user gets to decide when they upgrade the toolchain so it wouldn't be "no warning" if they wrote about the change in the release notes. I'd much rather they break code relying on undocumented weird behavior, than document the weird behavior and keep it alive indefinitely.
  - TylerE 13y ago
    That might be right - in this instance - and the actual cost might (or might not) be low - in this instance, but that's not worth breaking the promise Go has made to developers...that code remains compatible across minor forward versions.
  - enneff 13y ago
    If we let small semantic changes like this in, it would be too onerous to upgrade, and so nobody would upgrade. Go users should not have to read and understand all these tiny changes, look through their code to see if anything breaks, and finally make the correct fix. It's just not tenable, and we know this from experience (before Go 1 we introduced breaking changes with each stable release). FWIW, this is the first time we've encountered this bug, and it's been part of Go since it was released. Hardly worth breaking people's code for.
  - kisielk 13y ago
    It's not always obvious if a semantic change that's documented in the release notes will break your code. You might not know you use the code, the particular behaviour might not be covered by your test suite, etc. I like the fact I can upgrade to the latest Go version without having to worry things like that will happen.

by tux21b 13y ago

enneff 13y ago

It's much better for the core team to compromise a little than force everyone to update their code all the time. In particular, small semantic changes that can't be caught statically will just break people's code with no warning whatsoever. That's bad.

bluehex 13y ago
The end user gets to decide when they upgrade the toolchain so it wouldn't be "no warning" if they wrote about the change in the release notes. I'd much rather they break code relying on undocumented weird behavior, than document the weird behavior and keep it alive indefinitely.
- TylerE 13y ago
  That might be right - in this instance - and the actual cost might (or might not) be low - in this instance, but that's not worth breaking the promise Go has made to developers...that code remains compatible across minor forward versions.
- enneff 13y ago
  If we let small semantic changes like this in, it would be too onerous to upgrade, and so nobody would upgrade. Go users should not have to read and understand all these tiny changes, look through their code to see if anything breaks, and finally make the correct fix. It's just not tenable, and we know this from experience (before Go 1 we introduced breaking changes with each stable release). FWIW, this is the first time we've encountered this bug, and it's been part of Go since it was released. Hardly worth breaking people's code for.
- kisielk 13y ago
  It's not always obvious if a semantic change that's documented in the release notes will break your code. You might not know you use the code, the particular behaviour might not be covered by your test suite, etc. I like the fact I can upgrade to the latest Go version without having to worry things like that will happen.