API 兼容性。 这意味着库的后续版本提供与先前版本相同的 API，因此针对先前版本编写的程序仍然能够在新版本中编译和运行。 除了实际上保留相同的函数之外，这还意味着这些函数在新版本中执行与旧版本中相同的操作
应用程序二进制接口（ABI）兼容性。 这意味着在编译库时生成的二进制目标代码级别保留了向后兼容性。
API 和 ABI 兼容性之间通常存在一些重叠，但也存在重要差异。 为了保持 ABI 兼容性，您所要做的就是确保您的程序导出所有相同的符号。
这意味着所有相同的功能和全局可访问的对象都需要存在，以便与先前版本链接的程序仍然能够在新版本中运行。 可以在破坏 API 兼容性的同时保持 ABI 兼容性。 在 C 代码中，将符号保留在 C 文件中，但将它们从公共标头中删除，因此尝试访问符号的新代码将无法编译，而用户针对先前版本编译的旧代码将继续运行
The client base is key into determining whether or not you should support large backward compatibility issue.
Basically, you need to evaluate that like any other non-functional requirements you need to implement, and you need to carefully specify what is included in a "backward compatibility" feature:
API compatibility. This means that subsequent versions of a library provide the same API that previous versions do, so programs written against the previous version will still be able to compile and run with the new version. In addition to actually leaving the same functions around, this also implies that those functions all do the same thing in the newer version that they did in the older ones
Application Binary Interface, or ABI, compatibility. This means that backward compatibility is preserved at the level of the binary object code produced when you compile the library.
There is usually some overlap between API and ABI compatibility, but there are important differences. To maintain ABI compatibility, all you have to do is ensure that your program exports all of the same symbols.
This means all the same functions and globally accessible objects need to be there, so that programs linked against the prior version will still be able to run with the new version. It's possible to maintain ABI compatibility while breaking API compatibility. In C code, leave symbols in the C files but remove them from the public headers, so new code that tries to access the symbols will fail to compile, while old code that users compiled against the previous version will continue to run
client-server protocol compatibility. This means that a client using the version of the network protocol provided in the older releases will continue to function when faced with a newer server, and that newer client programs will continue to work with an older server.
data format compatibility. Newer versions of the code need to be able to work with data files written out by older versions, and vice versa. Ideally you should also be able to build some forward compatibility into data formats. If your file-handling routines can ignore and preserve unrecognized fields, then new functionality can modify data formats in ways that do not break older versions. This is one of the most critical kinds of compatibility, simply because users become very upset when they install a new version of a program and suddenly cannot access their old data.
If you combine the previous criteria (nature of the backward compatibility) with the nature of your client base, you can decide that:
If your clients are internal to your company, the need is lower, and 2.0 can break significant functions.
If your clients are external, a 2.0 might still break things, but you may need to provide migration guide
On the extreme, if your clients are the all world, as I already mentionned in this SO question about java, you may end up providing new functionalities without ever deprecating old ones! Or even preserving BUGS of your old products, because client's applications depends on those bugs!!
Does the age of the software affect your decision? Will you invest less time in backward compatibility when the program is newer?
I believe this has to do with what is already deployed: a recent program will have to deal with fewer backward compatibility needs than one which is around from 20 years.
Is the decision based solely on the number of clients with installed copies?
It should be based on a business case: does your migration - if needed because of a lack of backward compatibility - is able to be "sold" effectively to your clients (because of all the new shiny features it brings ?)
Do you make an active effort to produce code and file formats that supports future changes?
Trying to predict "future change" can be very counter-productive and quickly borderline to YAGNI (You Ain't Gonna Need It): a good set of migration tools can be much more effective.
When you're developing v1.0, do you try to built to make it easier for v2.0 to be backward compatible with v1.0? (Leaving "reserved" fields is an example.)
For the internal applications I have worked on, no. A Parallel Run is our way to ensure a "functional" backward compatibility. But that is not a universal solution.
How do you decide that "No, we aren't going to support that anymore" on features?
Again, for internal applications, the decision process can be very different than for an externally deployed one. If a feature does not bring any added value for the business, an internal "coherency" task is set to check with every other internal application the cost of their migration (i.e. "not using anymore this feature"). The same task is much harder to do with clients outside of your organization.
The more your system is used day-to-day, the more you should focus on it.
The more your system is deeply embedded in the core processes of your clients, the more you should focus on it.
The more your system has competitors, the more you should focus on it.
The more users that use older versions, the more you should focus on it.
The more complex and deeper buy-in there is for a client to your system, in terms of how big of an impact your software has on their business, the more you should focus on backward compatibility.
If you can't help them along onto new versions through attractive pricing, etc., it might be worth considering the risk to forcing everyone up.
Like Vista, or Office 2007. Those were terrific in helping me to Apple.
1.)If its a widely used product already by many clients, then i would make sure that the new version of this product is still using the same "base code"(Code which achieves basic functionality of the application under development). The new features should be factored into this code base or built on top of this code base with as little change needed in the execution environment of this application as possible. You don't want to make your existing users perform lot of changes in their existing installations. So its a trade-off between supporting a new functionality and revamp in the existing setup and usage process for the client.
2.)In a new product, If possible identify all possible features of that application right in the beginning even before v1.0 is out. Identify which features u are going to ship in v1.0. and which ones would be kept for later releases. Wherever possible keep these "later time features" in mind while design, code implementation, finalizing the output from/of the application to accommodate features in future versions. e.g. Leave additional elements/bit fields in your data structures.
My experience is with complex shrink wrap systems with relatively few (100 - 5000) users.
Marketing often has a gotta have it attitude on backward compatibility without a full appreciation of the lifecycle costs.
For example, the savings for maintaining bugs in your system for the current user base can easily be dwarfed by the support costs for new users over the lifetime of the system.
发布评论
评论（5）
客户群是确定是否应该支持大的向后兼容性问题的关键。
基本上，您需要像需要实现的任何其他非功能性需求一样对其进行评估，并且需要仔细指定 “向后兼容性”功能：
API 和 ABI 兼容性之间通常存在一些重叠，但也存在重要差异。 为了保持 ABI 兼容性，您所要做的就是确保您的程序导出所有相同的符号。
这意味着所有相同的功能和全局可访问的对象都需要存在，以便与先前版本链接的程序仍然能够在新版本中运行。
可以在破坏 API 兼容性的同时保持 ABI 兼容性。 在 C 代码中，将符号保留在 C 文件中，但将它们从公共标头中删除，因此尝试访问符号的新代码将无法编译，而用户针对先前版本编译的旧代码将继续运行
如果您将先前的标准（向后兼容性的性质）与客户群的性质结合起来，您可以决定：
如果您的客户位于公司内部，则需求较低，并且 2.0 可能会破坏重要功能。
如果您的客户端是外部的，2.0 可能仍然会破坏一些东西，但您可能需要 提供迁移指南
在极端情况下，如果您的客户是全世界，正如我在此关于java的问题，您最终可能会提供新功能而不会弃用旧功能！ 甚至保留旧产品的错误，因为客户的应用程序依赖于这些错误！！
软件的年龄会影响您的决定吗？ 当程序较新时，您会在向后兼容性上投入更少的时间吗？
我相信这与已经部署的内容有关：与 20 年前的程序相比，最近的程序必须处理更少的向后兼容性需求。
该决定是否仅基于已安装副本的客户端数量？
它应该基于业务案例：您的迁移（如果由于缺乏向后兼容性而需要的话）是否能够有效地“出售”给您的客户（因为它带来了所有新的闪亮功能？）
做您积极努力生成支持未来更改的代码和文件格式？
尝试预测“未来的变化”可能会适得其反，并且很快就会陷入 YAGNI（你不会需要它）的境地：一套好的迁移工具可以更加有效。
当您开发 v1.0 时，您是否尝试构建使 v2.0 更容易向后兼容 v1.0？ （保留“保留”字段就是一个示例。）
对于我开发的内部应用程序来说，没有。 并行运行是我们确保“功能性”向后兼容性的方法。 但这不是一个通用的解决方案。
您如何决定“不，我们将不再支持该功能”？
同样，对于内部应用程序，决策过程可能与外部部署的应用程序有很大不同。 如果某个功能不会为业务带来任何附加值，则会设置一个内部“一致性”任务，以与每个其他内部应用程序检查其迁移成本（即“不再使用此功能”）。 对于组织之外的客户来说，完成同样的任务要困难得多。
The client base is key into determining whether or not you should support large backward compatibility issue.
Basically, you need to evaluate that like any other non-functional requirements you need to implement, and you need to carefully specify what is included in a "backward compatibility" feature:
There is usually some overlap between API and ABI compatibility, but there are important differences. To maintain ABI compatibility, all you have to do is ensure that your program exports all of the same symbols.
This means all the same functions and globally accessible objects need to be there, so that programs linked against the prior version will still be able to run with the new version.
It's possible to maintain ABI compatibility while breaking API compatibility. In C code, leave symbols in the C files but remove them from the public headers, so new code that tries to access the symbols will fail to compile, while old code that users compiled against the previous version will continue to run
If you combine the previous criteria (nature of the backward compatibility) with the nature of your client base, you can decide that:
If your clients are internal to your company, the need is lower, and 2.0 can break significant functions.
If your clients are external, a 2.0 might still break things, but you may need to provide migration guide
On the extreme, if your clients are the all world, as I already mentionned in this SO question about java, you may end up providing new functionalities without ever deprecating old ones! Or even preserving BUGS of your old products, because client's applications depends on those bugs!!
Does the age of the software affect your decision? Will you invest less time in backward compatibility when the program is newer?
I believe this has to do with what is already deployed: a recent program will have to deal with fewer backward compatibility needs than one which is around from 20 years.
Is the decision based solely on the number of clients with installed copies?
It should be based on a business case: does your migration - if needed because of a lack of backward compatibility - is able to be "sold" effectively to your clients (because of all the new shiny features it brings ?)
Do you make an active effort to produce code and file formats that supports future changes?
Trying to predict "future change" can be very counter-productive and quickly borderline to YAGNI (You Ain't Gonna Need It): a good set of migration tools can be much more effective.
When you're developing v1.0, do you try to built to make it easier for v2.0 to be backward compatible with v1.0? (Leaving "reserved" fields is an example.)
For the internal applications I have worked on, no. A Parallel Run is our way to ensure a "functional" backward compatibility. But that is not a universal solution.
How do you decide that "No, we aren't going to support that anymore" on features?
Again, for internal applications, the decision process can be very different than for an externally deployed one. If a feature does not bring any added value for the business, an internal "coherency" task is set to check with every other internal application the cost of their migration (i.e. "not using anymore this feature"). The same task is much harder to do with clients outside of your organization.
您的系统日常使用得越多，您就越应该关注它。
您的系统越深入客户的核心流程，您就越应该关注它。
你的系统的竞争对手越多，你就越应该关注它。
使用旧版本的用户越多，您就越应该关注它。
客户对您的系统的支持越复杂、越深入，就您的软件对其业务的影响有多大而言，您就越应该关注向后兼容性。
如果你不能通过有吸引力的价格等帮助他们使用新版本，那么可能值得考虑强迫每个人升级的风险。
比如 Vista 或 Office 2007。这些对我选择 Apple 的帮助非常大。
The more your system is used day-to-day, the more you should focus on it.
The more your system is deeply embedded in the core processes of your clients, the more you should focus on it.
The more your system has competitors, the more you should focus on it.
The more users that use older versions, the more you should focus on it.
The more complex and deeper buy-in there is for a client to your system, in terms of how big of an impact your software has on their business, the more you should focus on backward compatibility.
If you can't help them along onto new versions through attractive pricing, etc., it might be worth considering the risk to forcing everyone up.
Like Vista, or Office 2007. Those were terrific in helping me to Apple.
我对软件向后兼容性的看法：
1.）如果它是许多客户已经广泛使用的产品，那么我会确保该产品的新版本仍然使用相同的“基本代码”（实现基本功能的代码）正在开发的应用程序）。 新功能应纳入此代码库或构建在该代码库之上，并且对该应用程序的执行环境进行尽可能少的更改。 您不想让现有用户在其现有安装中执行大量更改。 因此，这是支持新功能和修改客户端现有设置和使用过程之间的权衡。
2.) 在新产品中，如果可能的话，甚至在 v1.0 发布之前就从一开始就确定该应用程序的所有可能功能。 确定您将在 v1.0 中发布哪些功能。 以及哪些将保留以供以后发布。 在设计、代码实现、最终确定应用程序的输出以适应未来版本中的功能时，请尽可能记住这些“后期功能”。 例如，在数据结构中保留附加元素/位字段。
-广告。
My take on backward compatibility of software:
1.)If its a widely used product already by many clients, then i would make sure that the new version of this product is still using the same "base code"(Code which achieves basic functionality of the application under development). The new features should be factored into this code base or built on top of this code base with as little change needed in the execution environment of this application as possible. You don't want to make your existing users perform lot of changes in their existing installations. So its a trade-off between supporting a new functionality and revamp in the existing setup and usage process for the client.
2.)In a new product, If possible identify all possible features of that application right in the beginning even before v1.0 is out. Identify which features u are going to ship in v1.0. and which ones would be kept for later releases. Wherever possible keep these "later time features" in mind while design, code implementation, finalizing the output from/of the application to accommodate features in future versions. e.g. Leave additional elements/bit fields in your data structures.
-AD.
很多。 如果您不想惹恼您的每一位忠实客户！
A lot. If you don't want to piss off every one of your loyal customers!
我的经验是使用相对较少（100 - 5000）用户的复杂收缩包装系统。
营销人员通常对向后兼容性抱有一定的态度，而没有充分认识到生命周期成本。
例如，在系统的整个生命周期中，为当前用户群维护系统中的错误所节省的成本与新用户的支持成本相比很容易相形见绌。
My experience is with complex shrink wrap systems with relatively few (100 - 5000) users.
Marketing often has a gotta have it attitude on backward compatibility without a full appreciation of the lifecycle costs.
For example, the savings for maintaining bugs in your system for the current user base can easily be dwarfed by the support costs for new users over the lifetime of the system.