您如何应对用于项目的开源框架的变化？

这可能是我的个人怪癖，但我喜欢在生活中的项目中保持代码最新，包括它们使用的库/框架。部分原因在于，我认为如果Web应用程序已完全打补丁且为最新版本，则它将更加安全。在某种程度上，这只是我的一种强迫症。

在过去的七个月中，我们对软件进行了重大重写。我们删除了Xaraya框架，该框架速度很慢，并且作为产品基本上已经失效，然后转换为Cake PHP。（我们之所以选择Cake，是因为它使我们有机会非常快速地重写我们的软件，并且与Xaraya相比，性能得到了很大的提升，值得我们花时间。）

我们使用SimpleTest实施了单元测试，并遵循了所有文件和数据库命名约定等。

Cake现在更新为2.0。而且，似乎没有可行的升级路径。文件的命名约定已经发生了根本性的变化，它们放弃了SimpleTest，转而使用PHPUnit。

这几乎将迫使我们停留在1.3分支上，因为除非有某种转换工具，否则将无法更新Cake，然后逐步改进我们的旧代码以获取新Cake框架的好处。因此，像往常一样，我们将在Subversion存储库中得到一个旧框架，并根据需要自行对其进行修补。

这就是每次都能吸引我的原因。如此众多的开放源代码产品很难使基于它们的项目保持最新状态。当开发人员开始使用新的闪亮玩具时，将对较旧的分支机构进行一些关键的修补，但他们的大部分精力将集中在新的代码库上。

您如何处理所使用的开源项目中的根本性变化？而且，如果您正在开发开源产品，那么在开发新版本时是否牢记升级路径？

这个问题并非开源所独有。商业项目也会发生同样的问题。甚至更多，因为您没有资源，如果公司放弃支持，您可以维护自己。

最终用户类型的开源项目具有快速的升级周期，而旧版本则很快失去支持。另一方面，专为用户而付出大量努力的代码而设计的项目在进行重大升级后，对旧分支的支持周期往往较长。足够长的时间让您花时间先等待它稳定和成熟，然后再迁移并彻底测试您自己的代码。

抵制拥有最新和最大功能的诱惑可能很困难，但要意识到在稳定性和新功能之间存在软件方面的根本权衡。您不能不牺牲另一个而拥有一个。这就是存在bugfix分支的原因，因此您可以选择最适合您需求的范围。

我们已经通过模块化代码解决了这个问题。

我们的主要网站建于大约八年前，我们很幸运能由Spring框架的早期贡献者之一建立它，因此它是一个相当完善的基础。但是不幸的是，我们也很不幸，该开发人员在争论了前进的方向后决定分叉Spring，因此该代码库现在停留在Spring 1.1.4（或该年份的东西）的未维护分叉上。

我们试图重写代码以迁移到Spring的新版本，但是事实证明这非常困难。因此，我们的解决方案是开始使用Spring 3.x，Hibernate 3.6等最新框架，在完全独立的应用程序中以模块的形式构建网站的新功能。

现在，我们有两个在相同的基本URL上运行的Web应用程序，并且我们使用Apache的mod_proxy模块将每个路径分配给相应的应用程序。例如，“ / members”转到旧应用程序，“ / directories”转到新应用程序。但是，该网站的访问者不会知道他们使用的是不同的应用程序。对用户而言，它们看起来完全相同。

这两个应用程序需要进行通信，例如，当一个成员登录站点（使用我们的新应用程序）时，我们需要通知旧应用程序它们现在已经登录。我们使用简单的Web服务（仅向本地主机 事实证明，两个应用之间所需的集成量很小。

进行这项工作的重要部分是识别共享资产并将其打包在一起。因此，所有静态文本，图形，样式表，Javascript和模板都从原始应用程序移到了一个新的和旧的应用程序都使用的单独的第三个项目中。这样可以确保两个Web应用程序看起来和行为都相同，即使它们是完全独立的。

我想随着时间的流逝，我们将替换越来越多的原始应用程序，直到最终完全不需要它。这项技术的好处是，我们可以通过一系列小的，低风险的更改来缓慢地进行操作-无需大量且有风险的突然切换到新系统。

我并不总是这样做。许多开源项目都有针对先前主要版本维护的活动维护分支。有时，那些由需要维护该版本的人来维护。许多项目停留在主要版本上，直到他们自己准备好进行主要版本发布为止。

这就是每次都能吸引我的原因。

每次？您必须做出错误的选择。必须有一个没有发生这种情况的例子。

当开发人员开始玩新的闪亮玩具时

这是一个提示。使用开源项目时，请避免使用闪亮的新玩具。避免发布1.0。

您如何处理所使用的开源项目中的根本性变化？

步骤1.非常非常谨慎地选择开源项目。始终比较两个或多个竞争项目。

步骤2.比较两个竞争项目时，请尝试了解所提供的“基本”功能以及它们如何实现。避免过早“嫁接”一种特定的API。

步骤3.拥抱“后期绑定”和“松散耦合”的设计原则。尝试与开源项目的更改隔离开来。

步骤4.明确比较开源项目与“自己动手”之间的成本/收益比较。偶尔创建自己的解决方案可能比应对开源解决方案更好。

更改文件名应该不会太难。是的，这是一个很大的丑陋脚本。是的，转换时必须运行数周。但这是有限的成本。

如果每次都发生，请制定更好的应对策略。由于您对现实世界的观察是它总是会发生，所以希望改变现实世界并没有多大帮助。您在变更方面有来之不易的经验。利用这一点。将其视为感染，并发展自己的免疫反应。