261

v1.2.3git のタグの命名規則として多くのプロジェクトが使用されているのを見てきました。私もいくつかの使用を見てきました1.2.3。公式に承認されたスタイルはありますか、またはいずれかを使用するための適切な議論はありますか?

4

8 に答える 8

183

GitHub で有名な Tom Preston-Werner によるSemantic Versioningのバージョン 1.0.0 には、これに対処するサブ仕様がありました。

タグ付け仕様（SemVerTag）

バージョン管理システム (Git、Mercurial、SVN など) を使用してコードを保存する場合は、このサブ仕様を使用する必要があります。このシステムを使用すると、自動化されたツールでパッケージを検査し、SemVer 準拠とリリースされたバージョンを判断できます。

  1. バージョン管理システムでリリースにタグを付ける場合、バージョンのタグは "vX.YZ" である必要があります (例: "v3.1.0" )。

ただし、議論の後、これは削除され、 SemVer 仕様の最新バージョン(執筆時点では 2.0.0) に は存在しなくなりました。同じ場所でのその後のディスカッション スレッドはさらに深くなり、新しい"v1.2.3" はセマンティック バージョンですか? SemVer のブランチの FAQ に追加されmasterていますが、執筆時点 (2 年以上後) では、この変更は公式にリリースされた仕様にはまだ存在していません。

于 2010-01-06T06:50:22.680 に答える
117

支配的な規則が 2 つあるようです (リリース自体に番号を付けるための合理的な基準も順守していると仮定します)。

  • v1.2.3
  • 1.2.3

の利点はv1.2.3、Git ドキュメント (および Mercurial ドキュメント) がその例でその形式を使用していること、およびLinux カーネルやGit自体などのいくつかの「権威」がそれを使用していることです。(前述のセマンティック バージョニングでは以前は使用されていましたが、現在は使用されていません。)

の利点1.2.3は、gitweb または GitHub が、フォームの tarball または zip ダウンロードを自動的に提供できることです(そしてpackagename-$tag.tar.gz、tarballに. または、直接 を使用して tarball のバージョン番号を生成することもできます。正式なリリース プロセスのない軽量プロジェクトの場合、これらの可能性は非常に便利です。また、セマンティック バージョニングは、バージョン番号付けの唯一の、または広く受け入れられている標準ではないことにも注意してください。また、GNOME などの注目すべきプロジェクトやその他の数え切れないほどのプロジェクトが、タグの命名を使用しています。package-v1.2.3.tar.gzgit describe1.2.3

これらのポジションを統合するにはおそらく遅すぎると思います。いつものように、一貫性を保ち、理にかなっています。

更新:このコメントで述べたように、GitHub はタグから「v」を取り除いた tarball 名を提供するようになりました。

于 2011-04-26T21:51:57.257 に答える
84

先行する 'v' の理由は歴史的なものです。古い SCCS (cvs、rcs) は、タグ識別子とリビジョン番号を区別できませんでした。リビジョン番号を検出できるように、タグ識別子は数値で始まらないように制限されていました。

于 2011-06-08T00:46:18.653 に答える
21

私が知っていることではありません。
ただし、Git では、タグと同じ名前のブランチを同時に使用することはできません。そのため、作品1.1用のブランチ " "がある場合1.1は、タグ " 1.1" を配置せず、たとえば " v1.1"を使用してください。

于 2010-01-05T13:28:46.170 に答える
11

プレフィックスなしでバージョンにタグを付ける新しいパッケージ マネージャーのアドバイスv( PHP プロジェクト のコンポーザーなど)。SemVer 2.0では、タグの指定については何もありません。競合を避けるために意図的に行われます。ただし、ドキュメントとテキスト参照に接頭辞を追加することをお勧めします。フルまたはドキュメントでは十分に冗長でエレガントなv形式の例として。v1.0.4version 1.0.4ver. 1.0.4

于 2014-02-02T07:25:28.433 に答える
9

私は基準を知りません。タグ名を選択するだけで、

VERSION = `git describe --tags`

私のビルドスクリプトで。したがって、タグの命名規則は、実際にはプロジェクトのバージョンの命名規則に依存します。

于 2010-01-05T14:01:24.977 に答える
9

リリース固有の作業にはブランチとタグを使用し、続いて実際のリリースをそれぞれ使用します。

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

すべての開発者は、コミットしようとしている作業が 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
于 2010-01-05T13:51:20.967 に答える
1

私が知っているベストプラクティスはありません。ここにいくつかのリンクがあります：

一般に、バージョニング ( 0.0.1、v0.2.1、...) は、いくつかの問題追跡と連携して、もっともらしいアプローチと見なすことができます。（..私は通常、v接頭辞付きのタグ名を使用しますが.. @VonCの回答も参照してください）

于 2010-01-05T13:33:42.227 に答える