何时牺牲向后兼容性?

时间:2010-10-01 19:18:54

标签: future-proof

基本上我想知道在应用程序中有这种行为,其中较新的版本要求使用旧版本创建的内容(自动)转换为较新的版本格式,但代价是向后兼容。

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

这种做法有利有弊吗?

我想在我正在编写的应用程序(3d内容创建)的上下文中,我正在考虑寻找可能的不同方法来及时创建(更快,更好,更高效),这可能只有在较旧的内容文件转换为以类似方式创建相同内容的新方式。

例如,也许v1有一个Shape课程,在v2中,您意识到通过使用PolySpline课程可以更加通用和快速地完成此课程。但是为了让旧的Shapes成为PolySplines,您将转换旧的内容文件,并且所有内容都与新版本兼容。

这是一个合理的想法吗?

2 个答案:

答案 0 :(得分:2)

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

答案 1 :(得分:1)

除非您拥有庞大的安装基础和严格的升级策略/成本(例如Microsoft与其Office),否则对于需要在旧版软件上打开新版本文件的用户应该没有问题。换句话说,人们经常升级,但很少降级

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