在一个完美的世界里，企业将能够不断地更新他们的软件，以确保它与编程语言的更新保持同步，因为它们在不断发展。然而，在现实中，更新你的代码库以反映编程语言的版本变化往往是说起来容易做起来难。
仅仅确定何时因语言更新而需要改变代码库，更不用说实施这些改变了，就会耗费大量的时间和资源。这就是为什么定义一个流程是很重要的：
- 何时以及如何升级你的代码库。
- 如何处理你所依赖的编程语言不可避免的寿命终结（EOL）公告。
有了这个流程，你就可以对所需的时间和资源做出战略性而非临时性的决定，以确保你的软件保持安全、受支持和可用。这篇文章解释了如何设计这样一个流程，以及在规划你所依赖的编程语言的升级或EOL策略时需要考虑哪些因素。
如何知道何时升级一个代码库
正如 研究一直表明的那样，代码库很少更新，如果有的话，是因为：
- 你可能会引入一连串的依赖性升级，最终使你陷入 依赖性地狱。
- 升级可能会引入新版本的依赖关系，这些依赖关系可能需要经过内部审查过程，以确定许可的合规性、可维护性、安全性等。
- 任何升级都很有可能最终破坏构建。
- 时间和资源往往被更好地用于创造新的特性/功能，而不是升级。
现实情况是，从一种编程语言的一个版本转移到另一个版本，很少有好的商业案例。在大多数情况下，你的软件不会获得任何重要的新功能，如果你的竞争对手也在使用相同的语言，当然也不会有新的差异化功能。
通常情况下，只有两个原因需要考虑升级到一种语言的新版本：
- 升级提供了对一个或多个关键问题的修复，包括安全漏洞和/或关键错误。
- 当前版本的编程语言正在被淘汰。
但这并不意味着你可以放弃你的责任而忽视升级。你仍然需要有一个程序来：
- 评估新版本的编程语言的能力，以及它是否解决了关键的安全/错误问题。
- 它是否提供了向后的兼容性，或引入了破坏性的变化。
- 你目前使用的语言版本的支持状态是否已经改变。
根据这些问题的答案，你应该能够衡量是否有必要进行升级，是否可能会造成问题，以及何时开始计划。
终结生命对编程语言意味着什么？
在编程语言的背景下，EOL代表一种语言的开发者将停止为其提供官方支持的日期。达到EOL日期的语言不再收到新的特性或功能，但更重要的是，它们不再收到解决安全漏洞的更新或修正性能问题的错误。
说白了，EOL状态通常并不意味着整个编程语言不再被支持。相反，EOL日期对应于一种编程语言的特定版本或发行版。例如， Python 3.7.13版本 将在2023年6月27日达到EOL状态。在该日期之后，Python的较新版本将继续被支持，但Python 3.7.13具体来说将不再被支持。
EOL日期在不同的编程语言和版本之间差异很大。通常情况下，EOL日期会提前几年公布，并在文档文件中注明。你也可以参考社区维护的网站，如 endoflife.date 来搜索EOL信息。
EOL日期如何影响应用程序？
仅仅因为你建立应用程序的编程语言现在是EOL，并不意味着你的软件会突然停止工作。从技术上讲，通常有可能在EOL之后继续运行应用程序，就像你 今天 可以 运行Windows XP ，尽管微软 在近十年前就停止支持它 。
然而，你运行应用程序超过EOL的时间越长，商业和技术风险都会继续增加。其中一些风险包括。
- 安全威胁。因为该语言将不再收到安全漏洞的补丁，你的应用程序可能会受到网络攻击。这与不良分子可以在支持的语言中针对的安全漏洞有以下不同。
- 对于受支持的语言，速度是最重要的，因为在补丁发布之前，不良分子有一个狭窄的窗口。出于这个原因，攻击通常不那么复杂，因为没有那么多时间来创建工具和脚本来利用特定的漏洞。
- 对于不支持的语言，攻击往往更复杂，采用更好的工具和脚本，专门针对已知的老漏洞。
- 性能和稳定性风险。重大的漏洞可能在EOL之后出现，可能会影响到性能、与新版本操作系统的兼容性，甚至是稳定性，例如可能出现的内存泄漏。在没有修复的情况下，你可能很难保持你的应用程序运行。
- 不支持的解释器。如果你使用的是Python或Perl这样的解释语言，最新的解释器有可能不再支持你的应用程序的运行。虽然你可能能够 在现代版本的操作系统（OS）上安装 旧版本的解释器 ，但这样做可能会使你依赖于非官方或不支持的解释器，这本身可能会有安全或性能风险。
- 合规风险。虽然没有一个主要的合规性框架明确禁止EOL语言，但许多合规性框架确实要求组织采取 "合理 "的努力来保持他们的软件安全和更新，如PCI-DSS。审计员可能会将EOL语言解释为违反了这一原则，从而导致合规性问题。
因此，虽然在技术上有可能继续运行一个依赖EOL语言的应用程序，但这样做远非理想。而且，你继续使用EOL语言的时间越长，你遇到安全、性能或合规问题的风险就越高。
编程语言升级和EOL最佳实践
如果你已经决定你可以忍受风险，并且想在EOL之后继续运行你的应用程序，那么实际上只有两个选择（这对升级来说也是如此）：
- DIY。咬紧牙关，拿出内部时间和资源来解决这个问题。
- 外包。让它成为别人的问题
如果你选择DIY选项，你将需要拿出大量的时间和内部资源来处理：
- 升级：重建你的运行环境，并浏览所有可能出现的问题。
- EOL：要么。
- 用新的语言/现有语言的新版本重写应用程序。
- 创建一个程序来跟踪和识别安全问题，并致力于建立（和保留）内部的专业知识来修复它们。
如果你选择了外包方案，你将需要找到一个可靠的合作伙伴，并为他们的服务做预算，其中应该包括：
- 代表你管理你的运行环境，和/或在出现安全问题/漏洞时进行修复。这可以释放大量的时间和内部资源，但你仍然需要通过你的CI/CD程序来验证升级/修复，以发现和解决你的专有代码可能出现的任何问题。
虽然升级通常可以在发生时处理，但理想情况下，你会希望在你的语言的EOL日期之前探索EOL选项，以便你可以做出明智的决定并相应地分配资源。
为了使这个过程系统化，考虑审查你目前的语言依赖性，并至少每年检查一次它们的EOL时间表。你可能还想用一个内部文件页来说明语言的依赖性和相应的EOL计划，这样你就可以一目了然地看到哪些EOL日期即将到来，以及你是否已经解决了它们。
结论
无论你如何处理，编程语言的升级和EOL的最后期限是一个挑战。然而，只要你提前计划，它们都不一定会成为你的企业的严重安全、性能或合规风险。如果是这样，就没有必要放弃创造收入的应用程序，无论其底层编程语言的官方EOL状态如何。
几十年来，ActiveState一直在为老化和EOL语言提供扩展支持。我们帮助我们的客户升级和管理他们的代码库，释放他们的内部资源，让他们致力于增值的特性/功能，而不是管理他们的开源语言。我们的服务包括：
- 管理发行版
- 从我们的第三方依赖目录中的依赖被审查，以确保安全，可维护性和适当的许可，根据你的企业准则。
- 运行时环境从源代码（包括本地库）中安全地构建，使用你的项目所需的依赖关系集。
- 运行时是为所有目标操作系统打包的，确保可重复的环境只包含一起工作的依赖。
- 可以选择通过我们的工件库来提供你所构建的依赖，以方便管理和分发。
- 依赖关系被监控，以防止漏洞和过时；创建具有更新依赖关系的分叉，供你随时使用。
- 随着时间的推移，依赖关系的目录和过渡性/操作系统的依赖关系被维护，所以你可以随时复制构建。
- EOL语言支持
- 对Windows、Linux、macOS、AIX、Solaris和传统的操作系统提供支持。
- 可以通过电话、电子邮件和聊天提供技术支持。
- 漏洞会通过回传的补丁、社区贡献者和我们自己的语言专家来解决。也会根据需要提供错误修复版本。
- 供应链安全是我们提供的服务的一部分，确保所有的依赖关系是安全的。
- 迁移援助也是可用的。
