@kmlx commented https://github.com/golang/go/issues/18964#issuecomment-278307245 https://github.com/golang/go/issues/18964#issuecomment-27830... I remember re

@kmlx commented https://github.com/golang/go/issues/18964#issuecomment-278307245 https://github.com/golang/go/issues/18964#issuecomment-27830... I remember reading about the release cycle here: https://github.com/golang/go/wiki/Go-Release-Cycle https://github.com/golang/go/wiki/Go-Release-Cycle Once a release candidate is issued, only documentation changes and changes to address critical bugs should be made. In general the bar for bug fixes at this point is even slightly higher than the bar for bug fixes in a minor release. We may prefer to issue a release with a known but very rare crash than to issue a release with a new but not production-tested fix. One of the criteria for issuing a release candidate is that Google be using that version of the code for new production builds by default: if we at Google are not willing to run it for production use, we shouldn't be asking others to.