<分区>
我在 github 上 fork 了一个 gem，我对它做了几个重要的更改，我计划提交一个 pull request。在我这样做之前，我想知道我是应该修改次要版本号还是让 gem 维护者决定如何对其进行版本控制。
看了“Etiquette: Version bump my fork of opensource project?”和“Git fork version etiquette”，似乎大多数人只是自己撞版本。
对于拥有开源项目的任何人，您认为这是冒昧的还是我只是多疑？
<分区>
我在 github 上 fork 了一个 gem，我对它做了几个重要的更改，我计划提交一个 pull request。在我这样做之前，我想知道我是应该修改次要版本号还是让 gem 维护者决定如何对其进行版本控制。
看了“Etiquette: Version bump my fork of opensource project?”和“Git fork version etiquette”，似乎大多数人只是自己撞版本。
对于拥有开源项目的任何人，您认为这是冒昧的还是我只是多疑？
最佳答案
如果您 fork 了一个存储库并且正在回馈同一个存储库，那么除非绝对必要，否则不要更改版本并且不要对 Ruby gem 文件进行任何更改。
让维护者自由决定何时发布库以及分配哪个版本。您不知道维护者是否有其他计划或正在做其他事情。
您甚至不知道您的更改是否以及何时会被合并。有可能在合并您的更改之前发布了其他版本，您将增加与甚至不属于补丁意义的一部分(例如版本控制)的文件发生冲突的风险。
我过去拒绝了一些补丁，因为批准它们意味着对破坏我的路线图的版本进行不必要的更改。作为一般规则，我拒绝所有更改不限于提交者提议的功能/错误修复的补丁。如果你查看 GitHub 上发布的 gem 的贡献指南，你会看到有几个项目提到了这条规则。
如果您将 gem 作为一个分支发布，那么您可以自由地做任何您想做的事情。
关于ruby - 开源项目中的版本控制礼仪？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21033712/