何时牺牲向后兼容性？答案

【问题标题】：When to sacrifice backwards compatibility?何时牺牲向后兼容性？
【发布时间】：2011-04-20 00:46:02
【问题描述】：

基本上，我想知道在新版本要求使用旧版本创建的内容（自动）转换为新版本格式的应用中是否存在这种行为，但以向后兼容为代价。

Visual Studio 对其.sln 文件执行此操作。

这种做法有什么优点/缺点吗？

我想在我正在编写的应用程序的上下文中（3d 内容创建），我正在考虑寻找潜在的不同方法来及时创建事物（更快、更好、更高效），只有在旧的内容文件被转换为新的方式，以一种看似相似的方式创建相同的东西。

例如，也许v1 有一个Shape 类，而在v2 中，您意识到可以通过使用PolySpline 类更通用、更快地做到这一点。但是为了让旧的Shapes 成为PolySplines，您需要转换旧的内容文件，一切都将与新版本兼容。

这是一个合理的想法吗？

【问题讨论】：

【解决方案1】：

我没有看到提到的一个因素是，是否几乎所有共享数据的人都可能使用相同版本的应用程序。例如，如果像乐谱编辑程序之类的东西以早期版本无法读取的格式保存，这可能会非常烦人，因为希望交换乐谱的人很可能不会运行相同版本的软件。另一方面，如果数据库只能由小商店内的用户访问，则计划只对每个人进行同步升级并完成它。

【讨论】：

我认为对于小型应用程序，如果有的话，应该不需要经常打乱文件格式。但是对于非常大的应用程序，如果您希望它始终具有 IMO 的最佳功能，这将变得不可避免。
我认为最好的方法可能是从一开始就设计一个数据结构，它可以用当前版本不理解的信息标记项目，并允许文件包含多个冗余信息以及有关上次编辑的信息。将文件导入旧版本，更改某些内容并将其保存回来可能会导致旧版本无法理解的信息的语义更改，但如果新版本可以注意到冗余数据中的不一致，它可能会标记可疑内容。

【解决方案2】：

除非您拥有庞大的安装基础和严格的升级政策/成本（例如 Microsoft 的 Office），否则您应该不会遇到用户需要在旧版本软件上打开新版本文件的问题。换句话说，人们经常升级，但很少降级。

您现在可以预见和考虑的一件事是创建 (a) 一些免费播放器，让拥有新格式文件和旧版本软件的用户看到这个新文件（并可能决定升级）和 (b) 转换器模块这会将较新的格式转换为较旧的格式，可能会删除一些不受支持的功能/元素。

【讨论】：