管理第三方开源库变更的最佳实践是什么？

Question

6

在最近的一个项目中，我不得不修改一个开源库以解决其中的一个功能缺陷。我遵循了创建"供应商源"存储库的SVN最佳实践，并在那里进行了更改。我还将补丁提交给了该项目的邮件列表。不幸的是，该项目只有几个维护者，他们更新非常缓慢。

在某些时候，我希望该库会被更新，我也希望我的项目能够使用升级后的库。但现在我有一个潜在的问题......

我不知道我的补丁是否已经应用于此第三方库的未来版本。我也不知道我的补丁是否仍然与升级组件的内部实现兼容。而且很可能到那时，其他人会维护我的项目。

我应该给这个库起一个特殊的名字，以便清楚地表明我们进行了特殊的修改（例如commons-lang-2.x-for-my-project.jar）吗？我应该只在README中记录补丁，并引用SVN位置和邮件列表项的链接吗？我认为没有一种选择在升级场景下都是绝对可靠的。

这种情况下的最佳实践是什么？

- Jeff Knecht

2个回答

1

除了Bert的答案之外，就版本控制部分而言，他的回答是不错的，我还建议您编写一些单元测试来覆盖您的更改。

别误会我的意思，我并不是说您应该只编写一两个单元测试然后忘记它。为了使回归测试/单元测试真正起作用，它需要系统地实施，并且需要成为项目自动构建过程的一致性部分。

显然，这也不容易，一旦您离开，您无法保证您的替代者/同事继续使用您的测试策略。因此，您必须记录、完善、简化并不断向同事和管理层进行教育。

- Stephan Branczyk

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Bert F · Accepted Answer

SVN《红皮书》中的“供应商分支”章节对此进行了很好的介绍。该章节中的示例似乎与您的情况非常相似：

现在你面临一个有趣的情况。您的项目可以以某种不连贯的方式容纳对第三方数据的自定义修改，例如使用补丁文件或完整的替代文件和目录版本。但是这些很快就会成为维护问题，需要一些机制来应用您的自定义更改到第三方代码，并且需要在跟踪每个连续版本的第三方代码时重新生成这些更改。

解决此问题的方法是使用供应商分支。供应商分支是您自己版本控制系统中的目录树，其中包含由第三方实体或供应商提供的信息。您决定吸收到您的项目中的供应商数据的每个版本都称为供应商放置。