预发布版本可以通过在补丁版本之后紧跟一个短划线和一系列点分隔标识符来表示。示例: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
答案 0 :(得分:8)
您可以选择类似于Git本身的政策(请参阅其tags in the GitHub repo):
v1.7.2-rc0
v1.7.2-rc1
v1.7.2-rc2
v1.7.2-rc3
v1.7.2
这个想法(如Choosing a good version numbering policy中所述)可以遵循:
“
master
”分支将包含标记为在特定时刻生产就绪的代码,“master
”必须始终可编辑。
“master
”分支中的代码必须具有偶数标记号。对于版本号,它将使用git describe命令创建,因为它是一种事实上的标准。
请参阅Canonical Version Numbers with Git:
git describe –tags –long
这给你一个字符串(在我的一个项目中)
2.1pre5-4-g675eae1
格式为
{last reachable tag name}-{# of commits since that tag}-#{SHA of HEAD}
这为您提供了一个“规范版本号”(拼写更正),它通过提交单调增加,并且在多个开发存储库中是唯一的。如果我们都在同一个HEAD上,它将返回相同的值。如果我们都共享相同的最新标记,但具有不同的提交,则SHA将是不同的。
您可以努力只使用master
版本号
{last reachable tag name}-0-#{SHA of HEAD}
(即仅标记提交)
但是这个想法是这种版本号(标签+ SHA)完全明确。