分叉的项目，我的版本号从哪里开始？

我分叉了一个项目，并做了很多更改。这个fork不仅是这里的一个小功能更改，而且是那里隐藏的bug修复，它是一个相当大的更改。仅大多数核心代码是共享的。

我在v2.5.0分叉了这个项目。有一段时间我开始在v3.0上对fork进行版本控制。但是我不确定这是否是正确的方法，主要是因为当该项目达到v3.0时，事情会变得混乱。但是我不想从v1.0或v0.1重新开始，因为那意味着项目的初期，不稳定和不透明。这是不正确的，因为大多数核心代码都非常完善和稳定。

我真的不知道该怎么办，所以我在这里问：处理这种情况的标准方法是什么？大多数分叉会重新开始，提高版本号还是执行我不知道的其他事情。

我见过的大多数fork都是从1.0版开始的。但是我想您也已经更改了fork的名称，所以我不确定如果您只是从v3.0开始，为什么会有混淆。

我要做的是更改项目名称，发布1.0版，并明确说明该项目是另一个项目的分支。我认为这种方法不会造成任何混淆。

如果您真的担心“ 1.0”标签，只需在1.0之后的短时间内发布2.0版...

拥有自己的路线图并坚持下去，从原始版本的编号开始，但不要试图与原始产品的当前版本竞争。

您可能要考虑您的项目是否（和多少）与原始项目相关。如果计划将新功能从原始项目移植到您的项目中，则可以考虑使版本号与原始版本匹配。

作为示例，请查看MariaDB，它是MySQL的分支。他们希望将其保留为MySQL的“替代”替代品，因此，例如MariaDB 5.2具有MySQL 5.2的所有功能。

参见：http : //kb.askmonty.org/v/mariadb-versus-mysql

注意：自从发布此答案以来，MariaDB与MySQL的分歧很大，现在正在遵循其自己的版本控制方案。

0.1可能表示婴儿期，但1.0+版本表示稳定。主要版本号（例如2.0、3.0）的增加通常表示功能有较大变化。

例如

• 我的应用程序的1.0版是用于通过安装程序运行测试脚本的工具，
• 2.0版消除了测试脚本和环境设置脚本之间的区别，
• 3.0版添加了一个GUI，用于将脚本编写为流程图。公认它们是不同的产品，但是即使版本1还是可以正常运行的产品，也完全稳定等。版本2和3的出现是因为确定这些重大更改将是好的。如果我们不需要这些大的更改，并且只是继续进行错误修复等。次要版本号应该增加到1.10、1.20等，这样就可以了。

我的意思是主要版本号并不表示成熟，它们表示主要功能集。 现在，这与如何对产品进行版本编号有关。

我之前见过的，我一直很喜欢的是，再次从1.0（或者，如果真的喜欢从3.0）开始进行版本控制，然后在方括号中说出最后一个原始版本的功能。

• 最初：“ MyFork v1.1（基于OrigProg v3.0）
• MyFork的一些改进网络：MyFork v1.3（基于OrigProg v3.0）
• OrigProg发布了一个主要版本，MyFork进行了合并：MyFork v2.1（基于OrigProg v4.0）
• 对MyFork进行了一些重大更改（可能无法再次轻松地与OrigProg合并）：MyFork v3.0（基于OrigProg v4.0）

如果有可能，将您的fork合并回原始项目。我对此不够强调。

重新获得您的版本号，然后使用您从中分叉的版本号加上日期后缀。