（ c ）
硬件或软件系统的向后兼容性意味着能够成功使用系统早期版本中的接口和数据。 该原理不仅适用于使用在相同程序的早期版本中创建的文件的程序，而且还适用于具有类似算法的情况。 例如，Perl支持与Perl打算替代的另一种语言Awk的向后兼容性。
如果系统的早期版本是通过支持内置功能（例如，挂钩，插件或API允许您向软件添加新功能）开发的，则向后兼容性将更容易实现，但是，向后兼容性（侧重于后向 ）领域中的所有内容都可能使开发人员头疼。
完全拒绝使用它-以前版本的系统和产品的用户会很沮丧，突然失去了所有累积的小工具或程序。 确保完全向后兼容-您将成为过去决策的人质，使您的产品沉重，缓慢甚至无法实现预期的性能提升。
每次，开发人员都会做出一个艰难的决定：产品是否应向后兼容。 这里根本就没有“客观上正确的”解决方案-世界上有足够的成功向后兼容和失败的例子。 也许某人的经验会帮助您立即做出正确的选择。
让我们再次更改标准
当他们决定忘记向后兼容性时，最引人注目的例子之一就是USB 3.1 Type C（USB-C）连接器的外观。 多年来，我们一直不知道问题所在：任何带有microUSB或miniUSB连接器的小工具都可以插入任何相应的USB端口。 但是USB-IF联盟创建了Type C连接器，它与数亿甚至数十亿个智能手机，电缆，充电器和其他小工具中的任何一个在机械上都不兼容。
另一个问题是，并非每条USB-C电缆，端口，设备和电源都彼此兼容：两端的某些USB-C电缆只能传输5 Gb / s，另一些与10 Gb / s兼容，并且有些不能用作食物。
对于曾经自己组装或升级计算机的人来说，情况很熟悉。 在过去的20到30年中，许多世代相继的公交车和港口发生了变化，几乎每一个都无法与以前的公交车向后兼容。 从字面上看，主板上的所有连接器都发生了变化，而且不止一次：处理器插槽，视频卡和RAM总线，用于连接驱动器和外围设备的连接器。
直到今天，处理器领域的一次不健康的跨越仍在继续：几年后您可以驱动的相当令人兴奋的模型无法再安装在新的主板上。 制造商很难抵制定期在用户中浪费无用的铁的诱惑，迫使他们为新型号携带资金的诱惑。 由于主板已经失效，三年前购买的处理器必须更换为几乎相同的处理器，因此缺乏向后兼容性并不能使人感到欣慰。
设计用于数据和电源的通用连接器可以成为设备上的唯一端口-这无疑是USB Type-C的优点。 您可能会发现小工具中缺乏向后兼容性，甚至会注意到其优势（更高的数据传输速度和其他电源设置），但是在软件行业中，新版本与旧版本的不兼容更为痛苦。 对于企业产品而言尤其如此，因为企业产品的成本和对业务流程的影响太大。
游戏开发
在PC生态系统中，游戏向后兼容已有数十年了。 DOSBox之类的实用程序甚至使我们可以玩最早的PC版本。 兼容性因素似乎很可能在 Windows的当前主导地位中发挥了作用 ，其中以很高的可能性过渡到新版本的系统不会带来问题。 是的，因此，32位版本的Windows支持启动16位Windows软件和某些MS-DOS软件（以及分别运行64位版本的32位程序），但是Microsoft拥有一个庞大的重型平台，具有甚至有bug的兼容性。
那控制台呢？
Ars Technica报告显示 Xbox One和Xbox 360用户如何使用他们的设备。 有趣的是，来自Microsoft前缀的报告中的数据与Sony Corporation的观点一致，该公司不认为PlayStation 4中的向后兼容性很重要。 据索尼互动娱乐欧洲公司负责人吉姆·瑞安（Jim Ryan）称，该功能的讨论比实际使用的要多。 尽管索尼确实提供了在PS4上下载PS1和PS2游戏的机会。
一些网站进行了自己的民意测验，以预测Xbox One和PS4的发布-然后注意到，许多玩家表示他们希望向后兼容。 微软引起了人们对与Xbox One的向后兼容性的广泛关注。 该功能通常实现得很好，但是现在它并没有真正吸引游戏玩家。
Nintendo DS和Wii产品线也有许多向后兼容的示例。
游戏开发人员更加热情地欢迎公司的努力-不再需要从头研究架构以利用新的控制台设备。 向后兼容性使基于通用体系结构的所有设备的发行版维护相对容易。
语言向后兼容
（ c ）
每种流行的编程语言都有明显的演变，其使用寿命大部分由一个版本指示：您拥有Java 5、6、7等，PHP 5.1、5.2、5.3等。每种新版本都可以纠正错误并添加功能。但是如果语言（或平台）存在根本性缺陷，那么开发人员要么避免它们（如果可以的话），要么学习与之共处。
语言开发人员从在工作中使用一种或另一种编程语言的程序员那里获得了很多反馈。 似乎有一天该语言的版本将发布，所有问题都将消失。 但这不会发生。 为什么这样 一种选择是向后兼容。
流行的PHP有其缺点，并且长期使用它的人都非常了解如何解决该语言的所有陷阱。 现在假设在该语言的新版本中，所有的缺点都已修复，但它们已失去向后兼容性。 结果，开发人员花费时间将代码更新为当前版本的PHP。 他可以花时间满足客户要求或引入新功能。
考虑到这些问题，即使是更好，更清晰，更安全的应用程序，也可以理解那些不想切换到新版本PHP的人的动机。您将说这是一个假设的例子。 也许……但是世界上仍然有一些程序员在使用COBOL ！ 该语言于1958年出现。 到1997年，大约2,400亿行COBOL代码被积极使用 ，用这种语言编写的代码处理了全世界90％的金融交易和75％的商业交易。 最有趣的是惊人的语言兼容性：60年代使用的COBOL可以在现代设备上工作。
原则上，有些产品不能破坏向后兼容性，因为这将终止它们。 例如，Java：这种语言的主要应用领域是业务应用程序，全世界已经编写了天文数字的代码行，包括庞大的公司代码库。 20年前编写的代码仍然有效。 如果明天有一个Java版本，其中的开发人员可以添加出色的功能，但又没有向后兼容性，那么没有人会花很多钱在开发严重且昂贵的应用程序上。 因此，甲骨文要么要么一辈子都要拖掉许多旧版本，要么为创新开辟道路，但与此同时却失去了大量客户。 第三种选择-在完全支持和开发下同时支持两个Java分支-公司本身不会同意。
一次，Python开发人员违反了向后兼容性，从而激怒了许多用户。 大多数程序员并不认为Python 2.x是“错误的”或包含“基本缺陷”。 他们没有PHP开发人员的抱怨。
如今，语言社区已分为两个阵营，尽管第二版本的大量现成库不允许许多人迁移到第三版本，尽管它为语言带来了许多强大的改进。 结果，坚定地认为“ Python 3是Python社区可能发生的最糟糕的事情 ”。
这个问题有一个缺点-Python 3于2008年12月发布，但是Django框架中的语言支持仅在五年后才出现 。
尽管C和C ++之间没有100％的兼容性，但即使在C ++中，也与早期语言函数（包括一些直接从C继承的函数）向后兼容。
技术债务积累
有时会出现问题，因为我们根本无法预测未来。 1981年，互联网对每个人都足够了-描述了第一个广泛使用的IPv4协议版本，使用32位地址，将4,294,967,296的地址空间限制为可能的唯一地址。
对于ARPANet，43亿个IPv4地址看起来绰绰有余。 IPv6出现在1998年（在RFC2460中进行了描述），但是该协议并未获得普及。 花费了十多年的时间来关注地址数量有限的问题。 然后，很明显，已开发和安装的IPv4软件和硬件的庞大基础要求保持IPv6与IPv4的向后兼容性。
“突然”发现IPv6的开发与以前的版本不完全兼容 -仅支持IPv6的主机无法连接到只能通过IPv4工作的主机。 从IPv4过渡到IPv6需要一个“两个堆栈”阶段，在此阶段中，主机将同时与两个协议栈交互，使用IPv6协议栈与其他IPv6主机交互，并使用IPv4协议栈与其他IPv4主机通信。 。
某些交换机，路由器和安全设备也与IPv6不兼容。 因此，向IPv6过渡的过程面临许多问题，这些问题以各种方式提出。 现有解决方案中没有一个可以称为理想解决方案，但是每个解决方案都能找到自己的应用。
软件向后兼容理念
当我考虑是否有必要保持新版本的兼容性时
在软件中，向后兼容性通常意味着文件和整个应用程序的大小会大大增加，但是最重要的不是这一点。 向后兼容通常需要携带历史包,，使用解释性语言通常会导致明显的性能损失。
具有向后兼容性，代码库会膨胀，应用程序的体系结构很复杂，应用程序的升级也很复杂。 人们希望拒绝使用旧的代码，并编写使用最新开发内容的紧凑，轻巧的代码。
例如，新版本的Skype不能再与Windows XP下的版本建立语音和视频连接。 而且，当然，有些用户希望忽略新版本，而希望保留旧版本，但非常熟悉。
是的，今天向后兼容性被认为是软件产品开发中最重要的条件之一。 它使用户最轻松地（因此很舒适）切换到新产品。 例如，对于游戏机制造商而言，重要的是要确保新游戏与旧产品的向后兼容性，以使潜在购买者的受众最大化。 但与此同时，开发人员更难以实现逼真的图形和物理效果的新水平，具有讽刺意味的是，这可能会降低系统对游戏玩家的吸引力。
我们自己偶尔也会遇到类似的问题。 编写Hotbox云存储解决方案时，您可以完全从头开始创建所有内容，也可以使用Mail和Mail.Ru Cloud中的现有开发。 从头开始编写可以使您一次摆脱所有累积的技术债务，但是这需要很长时间。 使用当前开发的缺点是我们仍然使用Perl语言，由于它不太流行，因此很难找到新的开发人员。 但是这种解决方案的优势远远超过了：多年来，使用这种语言，我们拥有大量的专业知识和工具。 由于及时发布产品至关重要，因此我们决定专注于使用Perl。
结果是目前完全适合我们的产品。 在这种情况下，“向后兼容”不仅限于一项服务的范围，我们不仅与其他项目的开发兼容，而且与我们自己的经验兼容。 意识到这一事实会导致一个简单的想法：并非总是一种新的语言，新的程序版本或新的小工具就可以解决您的任务。