很多时候不兼容的改动都是“无意识”的，开发者以为修改是向后兼容的，但实际上不是。这种错误我犯过不知道多少次了……
关于向后兼容这个话题，我推荐两个讲座，都有视频和讲义：
- How to design a Linux kernel interface,
https://archive.fosdem.org/2016/schedule/event/design_linux_kernel_api/- Detecting incompatible changes,
https://sourcegraph.com/blog/go/gophercon-2019-detecting-incompatible-api-changes简单做个总结。Linux kernel-userspace API 早期的失误造成的影响已经持续了几十年，很多还将继续影响下去。这些失误的来源多数是设计者想象不到下游开发者会以什么样的方式去使用这些 API 。
规避的措施就是自动化测试，而自动化测试需要对 specification 进行规范化。实际上推动了开发流程的改变，即先公开规范和 API 设计，提供实例代码，接受反馈并修改设计方案，最后再实现功能和测试。而不是过去的先做实现，然后公开 API 接口的模式。
（这个事情做到极致大概类似于 amazon ，先开发布会，然后再开发）
第二个讲座虽然是 Golang 的，但指导意义很大。核心是如何从技术上自动判定某个改动是否会影响兼容性，进而对如何编写“面向未来可兼容扩展”的 API 接口提供理论支持。Golang 的开发团队为 Go1 的兼容性做了很大的努力，有非常多的案例经验可以参考借鉴。