这个问题并不是针对任何特定技术，而是针对一般开发人员的问题。
我们都从经验中知道，事情会发生变化。框架不断发展，新功能被添加，东西被删除。
例如，使用 1.0 版“ABC”框架的产品在 2.0 版出现时如何适应（ABC 可以是 .NET、Java、Cocoa 或任何您想要的）？
一种解决方案可能是使框架向后兼容；这样为 1.0 编写的代码仍然可以在框架的 2.0 版本中工作。
另一个可能是选择性地仅针对框架的 1.0 版本，但这可能会留下许多未使用的新功能（许多 .NET 2.0 应用程序似乎都这样做）
关于我们作为开发人员应该做的最佳实践以保持我们的技术最新，同时不破坏我们的应用程序有什么想法吗？
预测并投资于变革。
许多企业似乎认为改变是一件坏事。它使原本的工作过程复杂化。但作为开发人员，我们倾向于以不同的方式看待事物。
更改，特别是新版本，可以带来许多好处，例如安全更新、性能增强和功能。很多时候，变化是不可避免的。那么，为什么不将其视为现实而不是惊喜呢？
您可以做一些事情，例如以非供应商特定的格式备份您的数据，以防某些新奇的技术无法奏效并且您需要跳槽。
此外，如果你有资源，你可以让新旧版本的东西同时运行。理想情况下，您不希望您的生产系统运行最新最好的软件，直到有人对其进行评估并签署它。诸如单元测试和生产系统的 beta/开发克隆之类的东西可以帮助这个过程。
应该拥抱变化，而不是害怕变化。开发人员、利益相关者和业务人员都应该与新技术和框架保持同步。始终准备好应对变化。在苏俄，API 与您保持同步！
哦，可能的答案....
我的想法虽然不是独一无二的（可以肯定），但非常像这样。
这并不是那么容易，但我相信最简单的答案可能是最好的答案。你必须向前迈进……
我看到的唯一两个“解决方案”就是您的建议：保留或升级到新框架。我认为一般来说，当您的 API 收到重大更新并且您的软件很重要时，最好评估升级的好处，如果这些好处超过升级所需的时间，那么最好的做法就是升级。
选择适合您业务的保守、有风险或介于两者之间的方法并坚持到底。
例如，如果您的公司致力于创新，您将需要能够使用最新版本的框架——或者至少可以自由地研究它们。你需要雇佣那些对这样的环境感兴趣并感到舒适的人——一些开发人员对此非常兴奋，而另一些则不那么兴奋。放入一些结构以使升级安全（分支和静态架构）。客户应该了解与这样一家尖端公司合作所获得的好处——如果你不向他们传达这一点，这可能不是他们重视的东西，当事情破裂时他们会（理所当然地）感到不安，因为的系统更新。
或者选择保守的方法。选择一个可靠的、陈旧的技术并且不打算更新它，除了小版本。用你的话来说，定位一个特定的版本。雇用欣赏这种环境的人。
或者在路中间选择更多的东西。
这些方法中的每一种都适用于不同的时间——我在不同的项目中处于两个极端。