This isn't the standard library though, and if it were then it wouldn't have been changed.
We have broken compatibility once before in the standard library for security reasons. The go1compat doc says we're allowed to:
https://golang.org/doc/go1compat
> Security. A security issue in the specification or implementation may come to light whose resolution requires breaking compatibility. We reserve the right to address such security issues.
Re:Golang SSH Security
by mbertschler on Saturday April 15, 2017 @05:17PM
(#14122910)
I didn't want to imply that. I meant that this kind of fix is a good reason to break something, and I am happy that they quickly reacted to this issue, and don't change everything all the time even though it is in the x/ packages and not covered by the standard library stability promise.
In general I am very happy that the big emphasis on a stable APIs was taken up by the community, and that we have a lot of stable packages out now (even though they might not be 100% stable like the standard library). Since I also have to work with NodeJs where changing APIs and packages are much more common, I came to really appreciate that fact about the ecosystem.
It's a special case though. The golang.org/x/ packages are experimental but also candidates for promotion to the standard library. Eg, "context".
But this sort of issue is exactly the sort of real-world review and hardening which justifies having a namespace for stuff to go _before_ it becomes stdlib.
This issue hit me while building a tool for internal use at my employer. I am using the glide vendoring manager for this project, added another dependency which triggered an update of all other dependencies. At that point my tool broke and forced me to actually think about host key verification.