加大力度！Go 将会增强 Go1 向后兼容性

大家好，我是煎鱼。,前段时间我们在写 Go1.20 新特性和变更时，发现了一个问题有悖论。,Go1 有兼容性承诺，但如果发现了 BUG，会破坏兼容性。那怎么办？是大胆修改，破坏掉，还是说设计如此，打死不改？,写了个开头结果阳了，现在阳康还咳嗽回来接着更。,在 Go1 引入了 Go 兼容性保障《Go 1 and the Future of Go Programs[1]》，也就是旧版本的 Go 程序也可以在继续 Go 的新版本中正确运行。,当然，凡事有例外，像是安全问题就是例外。,具体的完整细则如下图：,,我们常接触到的有以下几个：,Go 核心团队自述已经有 10+ 年的 Go1 兼容性保障的经验，对 Go 团队和用户来说都非常的有价值。,甚至近两年，Go 团队和业内把 Go 的高速发展归因于对 Go1 兼容性的保障的落地实施。,看起来还是有板有眼的。,虽然主观上 Go 团队认为做的比较好，但发现仍然存在进行了兼容性破坏的情况。因此 Go 现任当家 @Russ Cox 发起了《extending Go backward compatibility[2]》。,其认为值得扩展 Go1 的向后兼容性，以尝试更少地破坏程序，明确地进行 GODEBUG 的设置，便于声明变更项在何时适应使用和控制。,简单来讲，就是 Go1 兼容性承诺给 Go 带来了非常大的好处，要继续扩大优势项，把长板拉长。,那为什么会突然想搞这事？因为 Russ Cox 最近和 Kubernetes 团队交流，发现在过去的几年里，Go 平均每年大约会有一个 Kubernetes 的破坏性变更。,其认为 Kubernetes 肯定不是一个个例。虽然每年 1 次左右的频率并不高，但 Go 团队在 Go1 兼容性的目标是是 0 次。,以下是对 Kubernetes 造成重大更改的一些示例：,,有兴趣的同学可以细看，考虑大多数同学可能并不关心，所以我没有进一步展开。,现有与兼容性相关的 GODEBUG 设置包括如下：,在新提案中，Go 将会正式确定并扩大对 GODEBUG 的使用，将根据 go.mod 中的 Go 版本号来设置对应 GODEBUG，以提供超越当前兼容性准则所保证的兼容性。,,根据 go.mod 内的 go 版本设置 GODEBUG,也就是接下来将会延伸以往的 GODEBUG 配置项，扩大使用面。,新措施的具体内容如下：,更加具体的案例，跟现有的 GODEBUG 其实是类似。例如 Go1.20 引入了一个新的 GODEBUG zipinsecurepath。,会遵循以下流程规范：,Go 在这几年对 Go1 兼容性保障越来越看重，在今年将会进一步加强。该提案已经到了最终阶段，很有可能会被接受，且最新评论没有反对意见。,该提案将会加大在兼容性上 GODEBUG 的应用，且最重要的是，将会根据 go.mod 文件中的 Go 版本来调整 GODEBUG，这会是一个重大微调整。,唯一纠结的同学，主要是反馈很多 Go 开发者，不知道自己修改 go.mod 文件中的 go 版本时，会导致 GODEBUG 的变更，从而影响到程序，会比较隐晦。,想当年，rsc 给 go.mod 加 go 版本号时，表示还没想好用在哪里…我只想表示这棵树也埋的真深。,[1]Go 1 and the Future of Go Programs: https://go.dev/doc/go1compat,[2]extending Go backward compatibility: https://github.com/golang/go/discussions/55090