根据我的经验，向后/向前兼容性的承诺是软件工程行业的gilded cage。我特别注意到这是文档文件格式和编程语言/ API的情况。客户和合作伙伴在他们现有的数据或代码中断时讨厌它;但是，如果您永远不会破坏兼容性，那么您可以严格限制您的长期创新能力。传统兼容性的最佳实践
除了逐步弃用旧功能之外，是否有解决此问题的方法？像Windows 7的XP模式一样，虚拟化似乎是一种令人兴奋的可能性。有其他人吗？
此外，对于我们这些想要设计新系统的人来说，我们可以从过去的行业失误中汲取教训。
通过扩展创新，而不是通过重写公共API。具有与后端功能一致的通用公共接口。只要您向公共API模块提供他们期望的结果，您就可以随时重写私有模块。
在后端做一些改进，并尽可能保持API的一致性。创建新模块并在扩展API的公共部分时清楚地记录它们，如果您提供了新的更好的方法来完成旧方法的补充，旧方法的弃用将自然而然地出现。
对于文档格式，请始终包含版本号，并确保您有办法支持所有现有版本。与API一样，通过扩展来添加新功能，而不是通过重写。
如果您想对软件的整体架构进行根本性更改，请将新版本作为模块包含旧版本 - 这将导致更大的规模，但会更好地支持旧数据和程序。
使用XML作为您文件格式的基础，并且只添加到规范DTD中，不要删除。这样，你的文件应该与早期版本向后兼容，这是一个优点。
以下是一个很好的示例：使用SLF4J Bridges可以轻松地从Java中的一个日志记录模块迁移到另一个日志记录模块。