我见过很多项目使用v1.2.3作为git中标记的命名约定。我还看到一些人使用1.2.3。是否有官方认可的风格,或者是否有充分的理由使用这两种风格?


当前回答

在实际发布之后,我们分别为特定于发布的工作使用分支和标记:

o---o-----o---o---o--- ...   master
     \   /       /
      \ /       /
       o-------o--- ...      1.6 branch

每个开发人员都会在心里做出决定,决定他们即将提交的工作是否只适用于master,或者是否也与分支相关。您可以看到,对分支所做的更改被合并回master上,但是master上的一些更改永远不会在分支上进行(也就是说,在本例中,这些更改不是针对1.6发行版的)。

当我们准备好发布时,我们标记它,然后最后一次合并回来,我们用与分支相同的名称命名标记,但是有一个关于它是什么特定版本的额外标识符,例如。“1.6-release”或“1.6-beta”或“1.6-rc2”等等。

... ------o---o---o--o---o--- ...   master
         /       /
        /       /
... ---o------(*)--- ...      1.6 branch
          1.6-release

其他回答

新的包管理器建议标记不带前缀v的版本(如PHP项目的composer)。 SemVer 2.0没有任何关于标记规范的内容。这是为了避免冲突而故意做的。但是,建议在文档和文本引用中添加前缀v。作为示例格式为v1.0.4,而不是完整版本1.0.4或版本。1.0.4的文档足够冗长和优雅。

似乎有两个主要的惯例(假设你也遵守一些合理的标准来编号版本本身):

v1.2.3 1.2.3

v1.2.3的优点是Git文档(以及Mercurial文档)在其示例中使用了这种格式,而且Linux内核和Git本身等几个“权威”都使用这种格式。(前面提到的语义版本控制曾经使用它,但现在不再使用了。)

The advantages of 1.2.3 are that gitweb or GitHub can automatically offer a tarball or zip download of the form packagename-$tag.tar.gz (and I think it's quite established that a tarball should not be named package-v1.2.3.tar.gz). Alternatively, you can use git describe directly to generate tarball version numbers. For lightweight projects without a formal release process, these possibilities can be quite convenient. It should also be noted that Semantic Versioning is by no means the only or a universally accepted standard for version numbering. And notable projects such as GNOME as well as countless other projects do use the 1.2.3 tag naming.

我认为现在巩固这些地位可能为时已晚。一如既往,保持一致,讲得通。


更新:正如在这条评论中提到的,GitHub现在提供了一个去掉标签中的“v”的tarball名称。

在实际发布之后,我们分别为特定于发布的工作使用分支和标记:

o---o-----o---o---o--- ...   master
     \   /       /
      \ /       /
       o-------o--- ...      1.6 branch

每个开发人员都会在心里做出决定,决定他们即将提交的工作是否只适用于master,或者是否也与分支相关。您可以看到,对分支所做的更改被合并回master上,但是master上的一些更改永远不会在分支上进行(也就是说,在本例中,这些更改不是针对1.6发行版的)。

当我们准备好发布时,我们标记它,然后最后一次合并回来,我们用与分支相同的名称命名标记,但是有一个关于它是什么特定版本的额外标识符,例如。“1.6-release”或“1.6-beta”或“1.6-rc2”等等。

... ------o---o---o--o---o--- ...   master
         /       /
        /       /
... ---o------(*)--- ...      1.6 branch
          1.6-release

我不知道有什么标准。我只是选择我的标记名称,这样我就可以粘贴

VERSION = `git describe --tags`

在我的构建脚本中。因此,标记命名约定实际上取决于项目的版本命名约定。

语义版本1.0.0版本,由Tom Preston-Werner的GitHub成名,有一个解决这个问题的子规范:

标签规范(SemVerTag) 如果你使用版本控制系统(Git, Mercurial, SVN等)来存储您的代码。使用这个系统可以让自动化工具检查你的 包并确定SemVer遵从性和发布版本。 当在版本控制系统中标记版本时,版本的标记必须为 “vX.Y。Z”。“v3.1.0”。

然而,经过讨论后,这一问题被删除了,并且在SemVer规范的最新版本(撰写本文时为2.0.0)中不再存在。在同一个地方,后来的讨论更深入,并产生了一个新的“v1.2.3”是语义版本吗?被添加到SemVer主分支的FAQ中,尽管在撰写本文时(2年多以后),这个变化仍然没有出现在正式发布的规范中。