预发布版本可以通过在补丁版本之后附加破折号和一系列点分隔标识符来表示。示例:1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。
为了消除歧义,标记发布提交(从主分支提交)的“正确”方式是什么?
一些想法
v1.7.2-release
v1.7.2-master
v1.7.2-prod
v1.7.2-official
v1.7.2-stable
预发布版本可以通过在补丁版本之后附加破折号和一系列点分隔标识符来表示。示例:1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。
为了消除歧义,标记发布提交(从主分支提交)的“正确”方式是什么?
一些想法
v1.7.2-release
v1.7.2-master
v1.7.2-prod
v1.7.2-official
v1.7.2-stable
您可以选择类似于 Git 本身的策略(在 GitHub 存储库中查看其标签):
v1.7.2-rc0
v1.7.2-rc1
v1.7.2-rc2
v1.7.2-rc3
v1.7.2
这个想法(如选择一个好的版本编号策略中所述)可以遵循以下思路:
'<code>master' 分支将包含在给定时刻标记为生产就绪的代码,'<code>master' 必须始终是可编译的。
'<code>master' 分支中的代码必须具有偶数标记号。对于版本号,它将使用 git describe 命令创建,因为它是一种事实上的标准。
请参阅使用 Git 的规范版本号:
git describe –tags –long
这给了你一个类似的字符串(在我的一个项目的情况下)
2.1pre5-4-g675eae1
其格式为
{last reachable tag name}-{# of commits since that tag}-#{SHA of HEAD}
这为您提供了一个“规范版本号”(拼写更正),它通过提交单调增加,并且在多个开发存储库中是唯一的。如果我们都在同一个 HEAD 上,它将返回相同的值。如果我们都共享相同的 most-recent-tag,但有不同的提交,则 SHA 将不同。
您可以争取master
仅使用版本号,例如
{last reachable tag name}-0-#{SHA of HEAD}
(即仅标记提交)
但想法是这种版本号(标签+SHA)是完全明确的。