数字の並びとして表現される非負の整数でなければなりません。数字で構成される部分は、すべて、テキスト文字列としてではなく、数としての値に従って解釈され整列されなければなりません。数字で構成される部分は、すべて、ゼロであっても構いません。リリースを表す部分について後で記述する場合を除いて、数字の部分がゼロであることは、常にバージョンの整列で取り得る最小の値であること以外には、なんら特別な重要性を持ちません。プロジェクトにおける幅広いバージョン付与方法をよりうまく収容するために、この枠組みによって許容されています。従って、当該仕様で技術的に許容されているバージョン付与方法のいくつかは、新規プロジェクトにおいては強い非推奨になっています。これが問題になるケースでは、引き続く節に関連する詳細事項をまとめてあります。通常の公的バージョン識別子で構成されています。ローカルバージョンラベルは、その意味の点では特に指定はありませんが、文法の上ではいくらかの制約が課されています。示すために用いられます。他の統合されたシステムにとって破壊的に過ぎるであろうという場合に、特定のバグ修正をバックポートして適用することでアプリケーション開発者やシステム統合者によって作成されるかもしれません。ローカルバージョンラベルを包含することで、上流側のリリースを下流側のインテグレータによる潜在的に修正されたリビルドから区別することが可能になります。ローカルバージョン識別子の使用はこの種のリリースには影響を与えませんが、ソースコード配布物に適用した場合には、対応する上流のリリースと正確に同じコードを含んでいないかもしれないということを示します。一部として難なく統合することができ、16進数のハッシュ値での表現でフォーマットが不統一になることを避けるには、ローカルバージョンラベルは、以下に示す許容される一連の文字群に限定されなければなりません。数字で始まり、かつ、終わらなければなりません。分割される)各部分を別々に考えます。文字を含むのであれば大文字小文字を無視して辞書学的に比較されます。数字だけの部分と辞書学的な部分を比較する時には、常に、数字だけの部分が辞書学的な部分よりも大きいものとして比較されます。多数の部分を持つローカルバージョンは、短い方のローカルバージョンの部分部分が長い方のローカルバージョンの先頭の対応する部分と正確に一致する限り、常に、それより少ない数の部分を持つローカルバージョンよりも大きいものとして比較されます。それ自身のパブリックバージョンを定義するプロジェクトです。上流プロジェクトに追随し再配布するプロジェクトで、潜在的には、上流プロジェクトのその後のバージョンからセキュリティ上の修正やバグ修正をバックポートします。ローカルバージョン指定子は、上流プロジェクトを公開のインデックスサーバで公開する際に使用するべきではありませんが、プロジェクトのソースコードから直接に作成されたプライベートのビルド群を識別するために使っても構いません。追加の変更を含む下流プロジェクトのバージョンをリリースする時に用いられるべきです。パッケージインデックスは上流プロジェクトを列挙しホストすることだけを意図していますので、ローカルバージョン指定子の使用を許してはなりません。拡張メタデータを提供するべきです。いう用語で呼ばれます。それらを正しくアップグレードすることができないでしょう。リリース部分の比較と整序は、リリース部分の各部分の数としての値を順に比較します。リリース部分の構成要素の数が異なるものを比較するときは、必要に応じて短い方にゼロの部分を追加する形で補足します。:0.90.9.10.9.2...0.9.100.9.111.01.0.11.12.02.0.1...リリースシリーズとは、共通の前置部分で始まる任意の最終リリース番号の集合です。リリースシリーズの一部です。相異なるリリース番号とは見做されません。日付ベースのリリース構成部分もまた許容されます。プレリリースサイクルを使うものがあります。いう用語で呼ばれます。プレリリース構成部分は、非負整数を伴ったプレリリースの局面を示すアルファベット文字の識別子から構成されます。順序付けられ、次いでその局面内の数字の部分で順序づけられます。両方を受け入れても構いません。両方のリリースを作ることを禁止するべきです。修正するためにポストリリースを使うものがあります。いう文字列とこれに引き続く非負整数値で成り立っています。ポストリリースは、対応するリリースの直後に続き、かつ、後続のリリースの部分よりも前にある、そのような数字の構成部分を使って順序付けを行います。実質的にバグフィクスを含むようなメンテナンスリリースを公開するためにポストリリースを使用することは、強い非推奨の対象です。一般的に、もっと長いリリース番号を使う方がベターで、各メンテナンスリリースについて最後の部分を増加させていく方が良いでしょう。candidate注釈プレリリースのポストリリースを作成することは、人間がバージョン識別子を解釈する時に困難を生じるので、強い非推奨事項です。一般に、単純に数字の部分を一つ増加させることで新しいプレリリース番号を作成する方が、大幅にわかりやすいものです。システムパッケージング担当者は、後のプロジェクトリリースと干渉しないように、直接ソースコードから早期リリースを作りたいと望むかもしれません。いう文字列と、それに続く非負整数値で構成されます。旧リリースの後にある数値部分で順序付けされます。post-release注釈これらは継続的インテグレーションの目的では利用する価値がある一方で、プレリリースの開発リリースを一般目的の公開インデックスサーバ群に公開することは、人間が読んだ時に解釈するのが難しいバージョン識別子になってしまうので、強い非推奨とされています。そのようなリリースを公開する必要があるなら、数字部分を増加させた新しいプレリリースを代わりに作成する方が、よほどわかりやすいでしょう。ポストリリースの開発リリースもまた強い非推奨とされていますが、ソースコードの変更を含む可能性のあるフルメンテナンスリリースをポストリリースと表記しているプロジェクトには適切かもしれません。暗黙のうちに仮定します。場合だけなので、ほとんどのバージョン識別子はエポックを含んでいません。シンタックスがたくさんあります。ケースセンシティビティ#すべてのアスキー文字は、バージョン番号の中では大文字小文字の区別をせずに解釈されるべきであり、標準系は小文字です。ようなバージョン番号を許容します。通じて解釈され、出力の文字列へと標準化されます。標準化されることを意味します。ようなローカルバージョンで標準化済みのもののアルファベットと数字から成る構成部分の中では、これは適用されません。この部分の標準形式は、セパレータなしのものです。ようなバージョン番号を許容します。プレリリース記号と数字部分の間に使われるセパレータをも許容するべきです。ようなバージョン番号を許容します。ようなバージョン番号を許容します。それぞれのケースで、追加的な綴り方の部分は標準的な形式のものと同等であると見做されます。明示的に含めておく形です。ようなバージョン番号を許容します。許容し、また、セパレータを全部省略することも許容します。ようなバージョン番号を許容します。プレリリースでのセパレータと同様に、これによって、ポストリリースの記号と数字の間にオプションとしてのセパレータを置くことを許容します。ようなバージョン番号を許容します。ようなバージョン番号を許容します。プレリリースでの追加の綴り方と同様に、その標準形式と同等のものと見做されるべきです。あるものと仮定されます。ようなバージョン番号を許容します。記号を全く省略することを許容します。なければならず、他の形式は許されません。ようなバージョン番号が許容されます。この標準化方法は、暗黙裡のポストリリース番号のルールと同時に使われてはなりません。許容し、また、一切のセパレータを省力することを許容します。セパレータを使う形です。ようなバージョン番号を許容します。あるものと見做されます。ようなバージョン番号を許容します。expressions。