10

最近我使用了一个由单个开发人员创建的不错的 gem，它托管在 Github 上。

在我的工作中，我不得不对它进行了一些实质性的修改，增加了一些改进。有些是特定于项目的，有些是特定于 gem 的，还有一些是独立的改进。

对于特定于 gem 的改进（例如，错误修复），我分叉了 repo，应用了修复，并提出了拉取请求。

然而，然后，我注意到独立改进属于原始 gem 的并行、持续分支的类别。更清楚地说，你以前见过它；我重写了原始 gem 的视图以使用 Twitter Bootstrap 框架。所以，我也把它推送到了 Github，但是，当然，没有提出拉取请求——相反，我更新了 README 来解释有什么不同，并感谢 gem 的原作者。

我的问题是，在这种情况下还应该做什么，假设 gem 是其他人想要使用的东西并且要在 ruby​​gems 等上发布？我是否应该简单地编辑 .gemspec 并保持原作者的信息完整，但将我的信息添加到作者/电子邮件字段，并重写任何其他已更改的内容？还是应该完全重写 .gemspec？

此外，如果原始发行版具有远程测试框架（如travis.yml），这些应该被删除，还是留在原地？

是否还有其他通常必须更改/重新创建的文件？

到目前为止我已经更新了

.gemspec
README.md
CHANGELOG.md
lib/libraryname/VERSION.rb #called as a constant in .gemspec

最后一个问题本身提出了一个单独的额外问题，版本控制如何在并行发行版中工作？

4

1 回答 1

8

听起来您已经正确处理了错误修复/分叉。

根据 gem 的许可证，将其作为 yourname-originalname 发布。

您已经做出了整个社区可能感兴趣的实质性更改，这是分叉和发布的公认标准。

它还解决了您的奖金问题。更改您想要发布的任何内容。它现在基本上是一个新项目。当然还是要归功于原始开发人员:)

于 2013-02-11T20:03:15.503 回答