セマンティックバージョニングでは、バージョン番号に4つのコンポーネントを使用できますか？

Question

私が見たセマンティックバージョニングのすべての例は、使用中の3つのコンポーネントを示しています。 2つ以下のピリオド文字。 $DAYJOB、リリース番号には4つのコンポーネントを使用しています。

5.0.1.2

セマンティックバージョニングではこれが可能ですか？

より高レベルで議論の余地のある質問として、それは本当に重要なのでしょうか？セマンティックバージョニングを適用することは良い考えかもしれないと私は考え始めましたが、最終的にはPCIなどのエンティティがそれをオーバーライドします。

PCIコメントを明確にすべきでした。問題は、メジャーコンポーネントとマイナーコンポーネントが変更されたときに監査とそのコストが影響することであり、必ずしも真の新機能ではありません。たとえば、支払いに関連する機能が導入された場合、PCIのマイナー番号を増やします。しかし、GUIの何かに関連する新しい機能を追加しても、追加されません。パッチのみが変更されます。したがって、この場合、他の誰かがそれらの決定を行うため、開発者としての問題について実際に発言することはありません。

enderland · Accepted Answer

プロセスのオーバーヘッド/監査を回避するためだけに、通常の規則をバイパスしているようです。あれは……気になってる。

あなたがやっていることは、機能/マイナーバージョン番号を戻すために意図的に追加のバージョン番号（マイナーPCI桁）を意図的に作成し、トリガーしないようにすることです内部監査基準。

とにかく、セマンティックバージョニングについての質問に到達すると、セマンティックバージョニングの仕様は次のようになります。

バージョン番号MAJOR.MINOR.PATCHを指定して、次の値を増やします。

互換性のないAPI変更を行った場合のメジャーバージョン

下位互換性のある方法で機能を追加する場合のマイナーバージョン

下位互換性のあるバグ修正を行う場合のパッチバージョン。

プレリリースおよびビルドメタデータの追加のラベルは、MAJOR.MINOR.PATCH形式の拡張機能として利用できます。

鉱山を強調します。

それで問題は、プレリリース/ビルドのメタデータに4番目の文字を使用していますか？それとも、リリースしているのは基本的に別のバージョンの表示ですか？

「はい」の場合、セマンティックバージョニングの仕様で許可されています。「いいえ」の場合、技術的にはセマンティックバージョニングに従っていません。

より高レベルで議論の余地のある質問として、それは本当に重要なのでしょうか？

厳格にそれに従いたいかどうかは、あなたとあなたのチームがしなければならない決定です。セマンティックバージョニングの目的は、APIの互換性を支援することです。

APIに影響しないバグ修正により、パッチバージョンが増加し、下位互換性のあるAPIの追加/変更によりマイナーバージョンが増加し、下位互換性のないAPI変更によりメジャーバージョンが増加します。

このシステムを「セマンティックバージョニング」と呼びます。このスキームでは、バージョン番号とその変更方法は、基礎となるコードの意味と、あるバージョンから次のバージョンに変更されたものを伝えます。

これは、バージョン管理がAPIのダウンストリームユーザーに影響を与えるときに、それをより明確にするのに役立つシステムです。

APIが同様に明確である限り、どちらの方法を選択しても大したことではありません。たとえば、3.4.2を使用していて、3.4.10にアップグレードする必要がある場合など、セマンティックバージョニングはたまたま単純ですが、何も壊さずに実行できることはわかっています。新しいバージョンが3.5.1の場合、下位互換性があることがわかります。そして、バージョン4.0.1が重大な変更になることは知っています。

これは、バージョン番号の意味のすべてです。

@enderlandはい、基本的には。 MAJOR（PCI）.MINOR（PCI）.FEATURE.HOTFIX + BUILD。基本的に、PCI（およびその後、会社のPCIオーバーロード）を関与させることなく、3番目と4番目のコンポーネントのみを変更できます。私にはこれは少し不自然であるように思えますが、バージョン番号の管理方法が正当化されているかどうかはわかりませんが、PCIと監査プロセスについて十分に理解していないため、別の言い方をします。

はい、これで結構です。あなたはあなたのために働き、あなたのニーズを満たすシステムを持っています。これがバージョン管理のポイントです。

APIがプライベート（内部向けのみ）の場合、あなたとそれを使用するすべての人にとって意味がある限り、バージョンをどのように設定してもかまいません。標準形式でのバージョン管理が重要なのは、「このバージョンの意味」を知る必要があるAPIの他の多くのコンシューマーがいる場合です。

任意のバージョン管理システムがあると、セマンティックバージョニングなど、他のシステムに慣れている人々を混乱させます。しかし、バージョン管理システムを作成している人を除いて、だれも実際にバージョン管理システムを使用していない場合は、問題ではありません。

Thomas Owens · Answer

2.0.0であるセマンティックバージョニングの現在のバージョンでは、いいえ。バージョンをX.Y.Zの形式で定義する要件があります。ここで、X、Y、およびZは、先行する0を含まない非負の整数です。

通常のバージョン番号は、X.Y.Zの形式をとる必要があります。ここで、X、Y、およびZは負でない整数であり、先行ゼロを含んではいけません。 Xはメジャーバージョン、Yはマイナーバージョン、Zはパッチバージョンです。各要素は数値的に増加しなければなりません。例：1.9.0-> 1.10.0-> 1.11.0。

ただし、メタデータを追加する機能は次の場合に許可されます。

ビルドメタデータは、パッチまたはプレリリースバージョンの直後に、プラス記号と一連のドットで区切られた識別子を追加することによって示すことができます。識別子はASCII英数字とハイフン[0-9A-Za-z-]のみで構成する必要があります。識別子を空にすることはできません。ビルドのメタデータはバージョンの優先順位を決定するときに無視する必要があります。したがって、異なる2つのバージョンのみビルドメタデータの優先順位は同じです。例：1.0.0-alpha + 001、1.0.0 + 20130313144700、1.0.0-beta + exp.sha.5114f85。

ただし、セマンティックバージョニングは、パブリックAPIを宣言するソフトウェア専用であることに注意してください。

セマンティックバージョニングを使用するソフトウェアは、パブリックAPIを宣言する必要があります。このAPIは、コード自体で宣言することも、ドキュメントに厳密に存在することもできます。それがどのように行われたとしても、それは正確かつ包括的でなければなりません。

これは、アプリケーションレベルではなく、ライブラリまたはサービスの開発をサポートする傾向があります。

考慮すべき重要なことは、内部使用と外部使用の両方に対するバージョン番号の意味です。バージョンは、ソフトウェアの違いについて2つの異なる時点で話すことができる単なる識別子です。セマンティックバージョニングはこれに関するルールを設定する1つの方法であるため、アプリケーションがセマンティックバージョニングを使用していることがわかっている場合は、パッケージの更新に必要な作業のレベルをより簡単に判断できます。共通の標準に従うことは良いかもしれませんが、何らかの理由でそれができない場合は、ユーザーのルールを文書化することで十分です。