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

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

5.0.1.2

セマンティックバージョニングはこれを許可しますか？

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

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

プロセスのオーバーヘッド/監査を回避するためだけに、通常の規則をバイパスしているようです。それは...に関する懸念として私を打つ。

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

とにかく、セマンティックバージョニングに関する質問に答えると、セマンティックバージョニングの仕様は次のように述べています。

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

• 互換性のないAPIを変更した場合のメジャーバージョン、
• 下位互換性のある方法で機能を追加する場合のマイナーバージョン
• 後方互換性のあるバグ修正を行うときのパッチバージョン。
• プレリリースおよびビルドメタデータの追加ラベルは、MAJOR.MINOR.PATCH形式の拡張機能として利用できます。

強調鉱山。

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

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

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

厳密にそれに従うかどうかは、あなたとあなたのチームが決めなければならない決定です。セマンティックバージョニングの目的は、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と監査プロセスについて十分に知りません。

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

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

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

では2.0.0であるセマンティックバージョニング、現在のバージョンがありません、。X、Y、Zが先頭の0を含まない非負の整数である形式XYZとしてバージョンを定義する要件があります。

通常のバージョン番号は、X、Y、およびZが非負の整数であるXYZの形式をとる必要があり、先行ゼロを含めることはできません。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つの方法です。したがって、アプリケーションがセマンティックバージョニングを使用していることがわかっている場合は、パッケージの更新に必要な労力のレベルをより簡単に決定できます。共通の標準に従うことは良いかもしれませんが、何らかの理由でできない場合は、ユーザーのルールを文書化するだけでも十分です。