バージョン指定子

この仕様では、 Python ソフトウェア配布物のバージョンを識別したり、特定のバージョンにおける依存関係を宣言したりする枠組みを記述します。

用語定義

この説明文書におけるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は、 RFC 2119 に記述されているように解釈されます。

"ビルドツール <Build tools>" とは、開発システムを走らせてソースコード配布物やバイナリ配布物のアーカイブを生成することを意図した自動化ツールのことです。ビルドツールは、また、ビルド済みのバイナリのアーカイブではなくて sdist として配布されるソフトウェアをビルドする目的で統合ツールから起動されることもあります。

"インデックスサーバ <Index servers>" とは、バージョンと依存関係のメタデータを広報し、許されるメタデータに制限を加えるような、正規の配布物の登記所にあたるものです。

"出版ツール <Publication tools>" とは、開発システムを走らせ、ソースコード配布物やバイナリ配布物のアーカイブをインデックスサーバへアップロードすることを意図した自動化ツールのことです。

"インストールツール <Installation tools>" とは、デプロイメントターゲット上で走らせ、インデックスサーバもしくは別途指定された場所から得たソースコード配布物やバイナリ配布物のアーカイブを入力として、ターゲットとなるシステムに配置することを意図した統合ツールです。

"自動化ツール <Automated tools>" とは、ビルドツール・インデックスサーバ・出版ツール・統合ツールや、配布物のバージョン・依存関係メタデータを作り出したり入力として扱うその他のソフトウェアを集合的に包含する用語です。

バージョン番号枠組み

配布物は、すべての定義されたバージョン比較操作をサポートしている公的バージョン識別子によって識別されます。

バージョン枠組みは、特定の配布物アーカイブによって提供される配布物のバージョンを記述するためにも使われますし、同様に、当該ソフトウェアをビルドしたり走らせたりするために必要な依存関係にあるバージョンに対して制約を加えるためにも使われます。

公的バージョン識別子

正統な公的バージョン識別子は、以下の枠組みに合致していなければなりません:

[N!]N(.N)*[{a|b|rc}N][.postN][.devN]

公的バージョン識別子は、先頭もしくは末尾に空白文字を含んではなりません。

公的バージョン識別子は、その配布物の中で一意でなければなりません。

インストールツール <Installation tools> は、この枠組みに合致しない公的バージョンのすべてを無視するべきですが、以下に指定される標準化も含んでいなければなりません。インストールツールは、バージョンが非適合であったり曖昧であったりした時には、ユーザに対して警告を行なっても構いません。

正統なフォーマットに厳密に適合していることを確認するための正規表現についても、さらに標準化する必要があるかもしれない入力を受け入れるためのより緩やかな正規表現についても、これらを提供する 補遺: 正規表現を伴うバージョン文字列を解析する を見てください。

公的バージョン識別子は５個の部分に分割されます:

• エポック部分: N!

• リリース部分: N(.N)*

• プレリリース部分: {a|b|rc}N

• ポストリリース部分: .postN

• 開発リリース部分: .devN

どのリリースであっても、この後の節で定義する "最終リリース <final release>"・"プレリリース <pre-release>"・"ポストリリース <post-release>"・"開発リリース <developmental release>" になることでしょう。

数字で構成される部分は、すべて、 ASCII の数字の並びとして表現される非負の整数でなければなりません。

数字で構成される部分は、すべて、テキスト文字列としてではなく、数としての値に従って解釈され整列されなければなりません。

数字で構成される部分は、すべて、ゼロであっても構いません。リリースを表す部分について後で記述する場合を除いて、数字の部分がゼロであることは、常にバージョンの整列で取り得る最小の値であること以外には、なんら特別な重要性を持ちません。

注釈

読解困難なバージョン識別子のいくつかは、既存の公開または非公開の Python プロジェクトにおける幅広いバージョン付与方法をよりうまく収容するために、この枠組みによって許容されています。

従って、当該仕様で技術的に許容されているバージョン付与方法のいくつかは、新規プロジェクトにおいては強い非推奨になっています。これが問題になるケースでは、引き続く節に関連する詳細事項をまとめてあります。

ローカルバージョン識別子

ローカルのバージョン指定子は、以下に述べる枠組みに適合しなければなりません:

<public version identifier>[+<local version label>]

プラスの文字によって公的バージョン識別子と区分されている任意の "ローカルバージョンラベル" を伴った、 (前の節で定義した) 通常の公的バージョン識別子で構成されています。ローカルバージョンラベルは、その意味の点では特に指定はありませんが、文法の上ではいくらかの制約が課されています。

ローカルのバージョン指定子は、上流のプロジェクトのパッチ適用済バージョンに互換性のある API (もし適用可能なら ZBI も) を示すために用いられます。例えば、上流の新しいリリースに更新することが当該アプリケーションや (Linux ディストロのような) 他の統合されたシステムにとって破壊的に過ぎるであろうという場合に、特定のバグ修正をバックポートして適用することでアプリケーション開発者やシステム統合者によって作成されるかもしれません。

ローカルバージョンラベルを包含することで、上流側のリリースを下流側のインテグレータによる潜在的に修正されたリビルドから区別することが可能になります。ローカルバージョン識別子の使用はこの種のリリースには影響を与えませんが、ソースコード配布物に適用した場合には、対応する上流のリリースと正確に同じコードを含んでいないかもしれないということを示します。

ローカルのバージョン指定子を確かなものにすることは、ファイル名や URL の一部として難なく統合することができ、16進数のハッシュ値での表現でフォーマットが不統一になることを避けるには、ローカルバージョンラベルは、以下に示す許容される一連の文字群に限定されなければなりません。

• ASCII 文字 ([a-zA-Z])

• ASCII 数字 ([0-9])

• ピリオド (.)

ローカルバージョンラベルは、 ASCII 文字ないし ASCII 数字で始まり、かつ、終わらなければなりません。

ローカルバージョンの比較や順序付けでは、ローカルバージョンの (. で分割される)各部分を別々に考えます。ある部分がすべて ASCII 数字でできているなら比較の目的においてはその部分は整数だと見做すべきであり、ある部分が一つでも ASCII 文字を含むのであれば大文字小文字を無視して辞書学的に比較されます。数字だけの部分と辞書学的な部分を比較する時には、常に、数字だけの部分が辞書学的な部分よりも大きいものとして比較されます。さらに、多数の部分を持つローカルバージョンは、短い方のローカルバージョンの部分部分が長い方のローカルバージョンの先頭の対応する部分と正確に一致する限り、常に、それより少ない数の部分を持つローカルバージョンよりも大きいものとして比較されます。

"上流プロジェクト" とは、それ自身のパブリックバージョンを定義するプロジェクトです。"下流プロジェクト" とは、上流プロジェクトに追随し再配布するプロジェクトで、潜在的には、上流プロジェクトのその後のバージョンからセキュリティ上の修正やバグ修正をバックポートします。

ローカルバージョン指定子は、上流プロジェクトを公開のインデックスサーバで公開する際に使用するべきではありませんが、プロジェクトのソースコードから直接に作成されたプライベートのビルド群を識別するために使っても構いません。ローカルバージョン指定子は、公開バージョン識別子で識別される上流プロジェクトのあるバージョンと API レベルで互換性を保つような、しかし、 (バグ修正などの) 追加の変更を含む下流プロジェクトのバージョンをリリースする時に用いられるべきです。Python パッケージインデックスは上流プロジェクトを列挙しホストすることだけを意図していますので、ローカルバージョン指定子の使用を許してはなりません。

ローカルバージョン識別子を使うソースコード配布物は、 (PEP 459 で定義される通り) python.integrator 拡張メタデータを提供するべきです。

最終リリース

リリース部分だけか、オプションとしてエポック識別子を加えたものから構成されているバージョン識別子は、 "最終リリース <final release>" という用語で呼ばれます。

ひとつかそれ以上の非負整数をピリオドで区切って構成されるリリース部分:

N(.N)*

あるプロジェクトの最終リリースは、首尾一貫して増加する形で番号付けされなければならず、そうでなければ自動化ツール <Automated tools> がそれらを正しくアップグレードすることができないでしょう。

リリース部分の比較と整序は、リリース部分の各部分の数としての値を順に比較します。リリース部分の構成要素の数が異なるものを比較するときは、必要に応じて短い方にゼロの部分を追加する形で補足します。

この枠組みの下では、最初の構成部分の後にいくつの追加部分があっても構いませんが、最も一般的な変種は、構成部分２個 ("メジャー.マイナー") のものか、または、構成部分３個 ("メジャー.マイナー.マイクロ") のものです。

例えば:

0.9
0.9.1
0.9.2
...
0.9.10
0.9.11
1.0
1.0.1
1.1
2.0
2.0.1
...

リリースシリーズとは、共通の前置部分で始まる任意の最終リリース番号の集合です。例えば、 3.3.1 ・ 3.3.5 ・ 3.3.9.45 は、すべて、 3.3 リリースシリーズの一部です。

注釈

リリース構成部分比較のルールでは、３個の構成部分を持つリリース番号と比較する時には、構成部分が２個のものを X.Y.0 へ暗黙裡に拡張するので、 X.Y と X.Y.0 は、相異なるリリース番号とは見做されません。

日付ベースのリリース構成部分もまた許容されます。リリースの年と月を使用した日付ベースのリリース枠組みの例:

2012.4
2012.7
2012.10
2013.1
2013.6
...

プレリリース

プロジェクトの中には、最終リリースに先立ってユーザによるテストを行えるように、 "alpha, beta, release candidate" のプレリリースサイクルを使うものがあります。

プロジェクトの開発サイクルの一部として使用されるなら、これらのプレリリースは、バージョン識別子のプレリリース構成部分を含めることによって表示されます:

X.YaN   # Alpha release
X.YbN   # Beta release
X.YrcN  # Release Candidate
X.Y     # Final release

リリース構成部分とプレリリース構成部分だけから構成されるバージョン識別子は、 "プレリリース <pre-release>" という用語で呼ばれます。

プレリリース構成部分は、非負整数を伴ったプレリリースの局面を示すアルファベット文字の識別子から構成されます。あるリリースにおけるプレリリース群は、まず局面 (alpha, beta, release candidate) で順序付けられ、次いでその局面内の数字の部分で順序づけられます。

インストールツール <Installation tools> は、既存のレガシーなディストリビューションのいくつかを取り扱うために、よくあるリリース構成部分に c と rc の両方を受け入れても構いません。

インストールツール <Installation tools> は、c バージョンを rc バージョンと同じである (つまり、 c1 が rc1 と同じバージョンである) と解釈するべきです。

ビルドツール <Build tools> ・出版ツール <Publication tools> 、そして インデックスサーバ <Index servers> は、共通のリリース構成部分に rc と c の両方のリリースを作ることを禁止するべきです。

ポストリリース

プロジェクトの中には、最終リリースにおける軽微なエラーで配布されているソフトウェアには影響を与えないもの (例えば、リリースノートの誤りを訂正する) を修正するためにポストリリースを使うものがあります。

プロジェクトの開発サイクルの一部として用いられる場合、これらのポストリリースは、バージョン識別子の中にポストリリース構成部分を含めることによって表示されます:

X.Y.postN    # Post-release

開発リリース構成部分なしでポストリリース構成部分を含むバージョン識別子のことを "ポストリリース <post-release>" という用語で呼びます。

ポストリリース構成部分は、 .post という文字列とこれに引き続く非負整数値で成り立っています。ポストリリースは、対応するリリースの直後に続き、かつ、後続のリリースの部分よりも前にある、そのような数字の構成部分を使って順序付けを行います。

注釈

実質的にバグフィクスを含むようなメンテナンスリリースを公開するためにポストリリースを使用することは、強い非推奨の対象です。一般的に、もっと長いリリース番号を使う方がベターで、各メンテナンスリリースについて最後の部分を増加させていく方が良いでしょう。

ポストリリースは、また、プレリリースにも使うことができます:

X.YaN.postM   # Post-release of an alpha release
X.YbN.postM   # Post-release of a beta release
X.YrcN.postM  # Post-release of a release candidate

注釈

プレリリースのポストリリースを作成することは、人間がバージョン識別子を解釈する時に困難を生じるので、強い非推奨事項です。一般に、単純に数字の部分を一つ増加させることで新しいプレリリース番号を作成する方が、大幅にわかりやすいものです。

開発用リリース

プロジェクトの中には、定期的に開発リリースを作成するものもあり、 (とりわけ Linux ディストリビューション向けの) システムパッケージング担当者は、後のプロジェクトリリースと干渉しないように、直接ソースコードから早期リリースを作りたいと望むかもしれません。

プロジェクトの開発サイクルの一部として使われる場合、このような開発リリース <developmental release> はバージョン識別子の中に開発リリース構成部分を含めることで表示されます:

X.Y.devN    # Developmental release

開発リリース構成部分を含むバージョン識別子のことを "開発リリース <developmental release>" という用語で表します。

開発リリース構成部分は、 .dev という文字列と、それに続く非負整数値で構成されます。開発リリースは、対応するリリースの直前 (で、かつ、同じリリース構成部分を持つあらゆるプレリリース部分の前のもの) で、かつ、 (任意のポストリリースを含む) 旧リリースの後にある数値部分で順序付けされます。

開発リリースは、また、プレリリースやポストリリースにおいても許されます:

X.YaN.devM       # Developmental release of an alpha release
X.YbN.devM       # Developmental release of a beta release
X.YrcN.devM      # Developmental release of a release candidate
X.Y.postN.devM   # Developmental release of a post-release

注釈

これらは継続的インテグレーションの目的では利用する価値がある一方で、プレリリースの開発リリースを一般目的の公開インデックスサーバ群に公開することは、人間が読んだ時に解釈するのが難しいバージョン識別子になってしまうので、強い非推奨とされています。そのようなリリースを公開する必要があるなら、数字部分を増加させた新しいプレリリースを代わりに作成する方が、よほどわかりやすいでしょう。

ポストリリースの開発リリースもまた強い非推奨とされていますが、ソースコードの変更を含む可能性のあるフルメンテナンスリリースをポストリリースと表記しているプロジェクトには適切かもしれません。

バージョンエポック

バージョン識別子に含まれる場合、エポックは、エクスクラメーションマークでリリース番号構成部分と仕切られて、他のすべての構成部分よりも前に出現します:

E!X.Y  # Version identifier with epoch

明示的にエポックが示されていない場合は、エポックとして 0 を暗黙のうちに仮定します。

明示的なエポックが必要となるのは、あるプロジェクトがバージョン番号を取り扱う方法を通常のバージョン順序付けルールが誤った回答を返すようなやり方で 変更した 場合だけなので、ほとんどのバージョン識別子はエポックを含んでいません。例えば、あるプロジェクトが 2014.04 のような日付ベースのバージョン番号を使っていたのに、 1.0 のようなセマンティックバージョン番号に変更したいとすれば、通常の順序付けの枠組みを適用した時に、新しいリリースが日付ベースのバージョン番号よりも よりふるいもの として識別されてしまうでしょう:

1.0
1.1
2.0
2013.10
2014.04

しかしながら、明示的にエポックを指定すれば、より新しいエポックに属するすべてのバージョン番号が、より古いエポックに属するものよりも後に続くものとして順序付けされるので、ソートの順序を適切に変更することができます:

2013.10
2014.04
1!1.0
1!1.1
1!2.0

正規化

既存のバージョン番号との互換性をより良く保つためには、バージョン番号を解釈する時に考慮に入れておかなければならない "代わりになり得る" シンタックスがたくさんあります。このようなシンタックスはバージョン番号を解釈する時には考慮しなければなりませんが、しかし、そのようなバージョン番号は上述の標準的なシンタックスに "正規化" されるべきです。

ケースセンシティビティ

すべてのアスキー文字は、バージョン番号の中では大文字小文字の区別をせずに解釈されるべきであり、標準系は小文字です。これによって、 1.1rc1 に標準化されるであろう 1.1RC1` のようなバージョン番号を許容します。

整数の標準化

あらゆる整数は、組み込みの int() を通じて解釈され、出力の文字列へと標準化されます。これは、整数のバージョン番号の 00 が 0 へと標準化され、09000 が 9000 へと標準化されることを意味します。 1.0+foo0100 のようなローカルバージョンで標準化済みのもののアルファベットと数字から成る構成部分の中では、これは適用されません。

プレリリースのセパレータ

プレリリースは、リリース構成部分とプレリリース構成部分の間のセパレータとして、 . ・ - または _ を許容するべきです。この部分の標準形式は、セパレータなしのものです。これによって、標準化すれば 1.1a1 になる 1.1.a1 や 1.1-a1 のようなバージョン番号を許容します。さらに、プレリリース記号と数字部分の間に使われるセパレータをも許容するべきです。これによって、 1.0a1 に標準化される 1.0a.1 のようなバージョン番号を許容します。

プレリリースの綴り方

プレリリース番号は、 a ・ b ・ rc ・ rc および rc を表す追加的な綴り方である alpha ・ beta ・ c ・ pre および preview を許容します。これによって、標準化すれば 1.1a1 ・ 1.1b2 ・ 1.1rc3 となる 1.1alpha1 ・ 1.1beta2 ・ 1.1c3 のようなバージョン番号を許容します。それぞれのケースで、追加的な綴り方の部分は標準的な形式のものと同等であると見做されます。

明示しないプレリリース番号

プレリリースでは、数字部分を省略することが許容されており、その場合には暗黙のうちに 0 が想定されます。この場合の標準形式は、 0 を明示的に含めておく形です。これによって、標準化すれば 1.2a0 になる 1.2a のようなバージョン番号を許容します。

ポストリリースのセパレータ

ポストリリースは、セパレータとして . ・ - や _ を許容し、また、セパレータを全部省略することも許容します。これの標準形式は、 . セパレータです。これによって、標準化すれば 1.2.post2 となる 1.2-post2 や 1.2post2 のようなバージョン番号を許容します。プレリリースでのセパレータと同様に、これによって、ポストリリースの記号と数字の間にオプションとしてのセパレータを置くことを許容します。これによって、標準化すれば 1.2.post2 となるであろう 1.2.port-2 のようなバージョン番号を許容します。

ポストリリースの綴り方

ポストリリースは、追加の綴り方である rev や r を許容します。これによって、標準化すれば 1.0.post4 になるであろう 1.0-r4 のようなバージョン番号を許容します。プレリリースでの追加の綴り方と同様に、その標準形式と同等のものと見做されるべきです。

明示されないポストリリース番号

ポストリリース番号では、数字部分を省略することが許容されていて、その場合には暗黙の裡に 0 であるものと仮定されます。これの標準形式は、明示的に 0 を含めることです。これによって、標準化すれば 1.2.post0 となる 1.2.post のようなバージョン番号を許容します。

暗黙裡のポストリリース

ポストリリースは、 post 記号を全く省略することを許容します。この形式を使う時には、セパレータは - でなければならず、他の形式は許されません。これによって、標準化すれば 1.0.post1 となる 1.0-1 のようなバージョン番号が許容されます。この標準化方法は、暗黙裡のポストリリース番号のルールと同時に使われてはなりません。換言すれば、 1.0- は正当なバージョン番号では なく 、 1.0.post0 へ標準化されることも ありません 。

開発リリース番号のセパレータ

開発リリースでは、セパレータとして . ・ - ・ _ を許容し、また、一切のセパレータを省力することを許容します。これの標準形式は、 . セパレータを使う形です。これによって、標準化すれば 1.2.dev2 になるであろう 1.2-dev2 や 1.2dev2 のようなバージョン番号を許容します。

暗黙裡の開発バージョン番号

開発リリースでは、数字部分を省略することができて、その場合には暗黙裡に 0 であるものと見做されます。これの標準形式は、明示的に 0 を含める形です。これによって、標準化すれば 1.2.dev0 となる 1.2.dev のようなバージョン番号を許容します。

ローカルのバージョン番号構成部分

構成部分のセパレータとして . を使うことに加えて、ローカルバージョン番号を使えば - や _ の使用も受け入れ可能です。標準形式は、 . 文字を使うことです。これによって、標準化すれば 1.0+ubuntu.1 となる 1.0+ubuntu-1 のようなバージョン番号も許容されます。

先駆する v の文字

よくあるバージョン番号の表記方法である v1.0 の形をサポートするために、バージョン番号は単独の v の文字が先行していても構いません。この文字は、あらゆる目的において無視されなければならず、バージョン番号の標準化された形式では省略されるべきです。 v の有無だけが異なるバージョン番号は、同一のものと見做されます。

先行する空白文字や後続する空白文字

先行する空白文字や後続する空白文字は暗黙の裡に無視されなければならず、バージョン番号の標準化された形式では除去されなければなりません。これには "" ・ \t ・ \n ・ \r ・ \f ・ \v が含まれます。これによって、標準化すれば 1.0 となる 1.0\n のようなバージョン番号に見られる、偶然に入り込んだ空白文字を実用的に取り扱うことができます。

枠組みに合致したバージョン番号の例

標準のバージョン番号の枠組みは、公開・非公開の Python プロジェクトにおける識別の慣行を広い範囲で包含するように設計されています。実際上、ある単独のプロジェクトでこの枠組みが提供するあらゆる自由度を使おうと試みるなら、上述のルールに従うすべてのツールが首尾一貫して順序をつけることができる一方で、人間のユーザにとってはバージョン番号間の相対的な順序を解き明かすことに困難を感じることになるでしょう。

この後に、プロジェクトがそのリリースを識別するために選択するかもしれない異なるアプローチで、 "最新リリース" と "最新のステーブルリリース" を人間も自動化ツールも簡単に決定できることが保証されたもののいくつかの例を示します。

単純な "メジャー.マイナー" バージョン付け:

0.1
0.2
0.3
1.0
1.1
...

単純な "メジャー.マイナー.マイクロ" バージョン付け:

1.1.0
1.1.1
1.1.2
1.2.0
...

アルファ・ベータや公開候補 <candidate> のようなプレリリースを伴う "メジャー.マイナー" バージョン付け:

0.9
1.0a1
1.0a2
1.0b1
1.0rc1
1.0
1.1a1
...

開発リリース <developmental releases> 、リリース候補 <release candidates> やポストリリースのある "メジャー.マイナー" バージョン付け:

0.9
1.0.dev1
1.0.dev2
1.0.dev3
1.0.dev4
1.0c1
1.0c2
1.0
1.0.post1
1.1.dev1
...

ゼロを飛ばして各年の中で増加するシリアル値を使った日付ベースのリリース番号:

2012.1
2012.2
2012.3
...
2012.15
2013.1
2013.2
...

許容される接尾辞と相対的な順序付けのまとめ

注釈

この節では、バージョニング方法を決めようとしている Python 配布物の開発者向けというよりは、むしろ、一義的には配布物のメタデータを自動的に処理するツールの作者に向けて書かれています。

バージョン識別子のエポック構成部分は、当該エポックの数値としての値に従って整序されなければなりません。エポック構成部分が存在しない場合には、暗黙のうちに 0 の値と解釈します。

バージョン識別子のリリース構成部分は、標準化されたリリース構成部分を解釈する時には以下のように Python のタプルソーティングと同じ順序で格納されていなければなりません:

tuple(map(int, release_segment.split(".")))

比較に関わるすべてのリリース構成部分は、必要に応じて不足する構成部分にゼロを補填することで長さを一致させなければなりません。

リリース番号の数字部分 (1.0 や 2.7.3) の中では、後述の接尾辞が許されており、下に示す通りに順序付けをしなければなりません:

.devN, aN, bN, rcN, <no suffix>, .postN

c が意味の上で rc と同等のものであると見做されていて、恰も本当に rc であるかのように並べ替えされる点を銘記してください。ツール群は、同じリリース構成部分内に c と rc の両方に同一の N を付けたものが来た場合には曖昧であるとしてこれを拒否しても構いませんが、これでも仕様には合致しています。

アルファ (1.0a1) 、ベータ (1.0b1) 、あるいはリリース候補 (1.0rc1, 1.0c1) の中では、後述の接尾辞が許されていて、示される通りに並べ替えられなければなりません:

.devN, <no suffix>, .postN

ポストリリース (1.0.post1) の中では、後述の接尾辞が許されていて、示す通りに並べ替えられなければなりません:

.devN, <no suffix>

バージョン番号の数字部分の直後に置く場合 (例えば 1.0.dev456 や 1.0.post1) であっても、 devN と postN は、常にドットに後続しなければならないことを銘記してください。

共通の先行部分を持つプレリリース構成部分、ポストリリース構成部分、あるいは開発リリース構成部分の中で、数値部分の値に従って順序付けをしなければなりません。

可能なバージョン番号の例を以下に示します:

1.dev0
1.0.dev456
1.0a1
1.0a2.dev456
1.0a12.dev456
1.0a12
1.0b1.dev456
1.0b2
1.0b2.post345.dev456
1.0b2.post345
1.0rc1.dev456
1.0rc1
1.0
1.0+abc.5
1.0+abc.7
1.0+5
1.0.post456.dev34
1.0.post456
1.0.15
1.1.dev1

相異なるメタデータバージョンを通してバージョン番号を順序付けする

メタデータ v1.0 (pep:241) および メタデータ (PEP 314) は、標準となるバージョン番号の識別や順序付けの枠組みを指定していません。しかしながら、メタデータ v1.2 (PEP 345) では、 PEP 386 で定義された枠組みを指定しています。

単純なインストーラ API の特性の故に、特定の配布物がどのバージョンのメタデータを使っているかをインストーラが意識することは不可能です。さらに、インストーラは、どのバージョンをインストールするべきであるかを決定するために、すべての、または、可能な限り多くのバージョンのプロジェクトを含む合理的に優先順位付けされたリストを作成することができるように要求されています。これらの要求事項によって、あるプロジェクトのすべてのバージョンにおいてひとつの解析メカニズムが使われるような標準化が必要とされます。

上記のことによって、この仕様では、全てのメタデータのバージョンに使われなければならず、メタデータ v1.2 であってさえも PEP 386 を上書きする形で使われなければなりません。ツール類は、この仕様に示された規則に従って解釈できないバージョン番号をすべて無視するべきですが、この仕様に合致するバージョン番号がひとつも利用可能でない時には、それぞれの実装で定義されたバージョン番号の解釈や順序付けにフォールバックしても構いません。

配布物のユーザは、自分が管理するプライベートなパッケージインデックスにおいて、合致しないバージョン番号を明示的に除去しても構いません。

他のバージョン番号の枠組みとの互換性

プロジェクトの中には、この使用で定義された公開のバージョン番号枠組みに合致するために翻訳を要求するようなバージョン番号枠組みを使うことを選択するものもあります。そのような場合には、当該プロジェクトに特有のバージョン番号をメタデータに格納しておく一方で、公開のバージョン番号を version フィールドに置くことができます。

これによって、自動化された配布物ツール類が公開されたリリース群の一貫性のある形で正確な順序付けを提供することができる一方、開発者側では依然として自分たちのプロジェクト向けに好みの内部的なバージョン番号枠組みを使うことが許されます。

セマンティックバージョニング

セマンティックバージョニング は、リリース番号の異なる要素の重要性に関して、この仕様以前から慣例として認められた人気のあるバージョン番号の識別の枠組みです。あるプロジェクトがセマンティックバージョニングの詳細を受け入れないことを選択した場合であっても、他の配布物に依存する時や他のプロジェクトが依存する配布物を公開する時に発生する多くの課題を網羅するためにも、この枠組みは理解しておくに値します。

(2.0.0 仕様の1-8 節の) セマンティックバージョニングの ("メジャー.マイナー.マイクロ" としてこの仕様に記されている) "メジャー.マイナー.パッチ" の形は、この仕様で定義されるバージョン番号枠組みと完全に互換であり、この形を受容することが推奨されています。

ハイフンを含むセマンティックバージョン (pre-releases - clause 10) やプラス記号を含むセマンティックバージョン (builds - clause 11) は、この仕様と 互換性がなく 、公開のバージョン番号フィールドでは許されていません。

ソースラベルに基づいたそのようなセマンティックバージョニングを公開バージョン番号と互換性のあるものに翻訳する可能なメカニズムの一つは、 .devN 接尾辞を使って適切なバージョン番号の順序を指定することです。

特定のビルド情報も、ローカルのバージョン番号のラベルに含めても構いません。

DVCS に基づいたバージョン番号のラベル

多くのビルドツールは、バージョン識別子に識別のためのハッシュ値を付加するために、 Git や Mercurial のような分散バージョン管理システムを統合しています。ハッシュ値は信頼できる形で順序付けすることができないので、そのようなバージョン番号は公開のバージョンフィールドでは許されません。

セマンティックバージョニングの場合と同様に、元の DVCS ベースのラベルをプロジェクトのメタデータに格納することができない一方で、そのようなリリースを公開する際に一意に識別するために、公開の .devN 接尾辞をつけても構いません。

ハッシュ値の情報を識別することは、ローカルのバージョン番号ラベルに含めても構いません。

Olson データベースによるバージョニング

pytz プロジェクトは、バージョニング方法を対応する Olson タイムゾーンデータベースのバージョニング方法から継承しています: 年と、それに後続する小文字の文字でその年の中でのデータベースのバージョンを示すもの。

これは、 <year>.<serial> として (訳註、標準に) 適合する公開のバージョン識別子に翻訳することができ、そこでは ('<year>' リリースに対して) シリアル番号が０か１から始まって、その年の内にデータベースが更新される度に１づつ増加されます。

他の翻訳されたバージョン識別子と同様に、対応する Olson データベースのバージョン番号は、そのプロジェクトのメタデータに記録しておくことが可能です。

バージョン指定子

バージョン指定子は、一連のバージョン番号節をコンマで区切ったものから構成されます。例えば:

~= 0.9, >= 1.0, != 1.3.4.*, < 2.0

比較演算子がバージョン番号節の種類を決定します:

• ~=: 互換性のあるリリース 節

• ==: バージョン番号のマッチング 節

• !=: バージョンの除外 節

• <=, >=: 境界を含む順序比較 節

• <, >: 境界を含まない順序比較 節

• ===: あらゆる意味での同一性 clause.

コンマ (",") は、論理 積 演算子と同一のものです: 候補バージョン番号は、全体として指定子に合致するために、すべての与えられた節が合致しなければなりません。

条件演算子とその後のバージョン識別子の間の空白文字は、コンマの周囲の空白文字と同様にオプションです。

複数の候補バージョンがバージョン識別子に合致する時には、好ましいバージョンは、標準の バージョン番号枠組み で定義された首尾一貫する順序付けによって決定される最新のバージョンです。プレリリースが候補バージョンだと見做されるか否かは、 プレリリースの取り扱い に記述されているとおりに扱われるべきです。

以下で特に注記される場合を除いて、バージョン指定子内ではローカルバージョン指定子は許されてはならず、あるバージョン指定子に合致する候補バージョンかどうかを調べる際にはローカルバージョンラベルは完全に無視されなければなりません。

互換性のあるリリース <Compatible release>

互換性のあるリリース節は、互換リリース演算子 ~= とバージョン識別子から構成されます。指定されたバージョンと互換性があるものと期待されるすべての候補バージョンに合致します。

指定されたバージョン識別子は、 バージョン番号枠組み <Version scheme に記述された標準フォーマットの範疇に収まっていなければなりません。ローカルバージョン識別子は、このバージョン識別子の中では許容されません。

あるリリース識別子 V.N にとって、互換リリース節は、一組の比較節とほぼ同一のものです:

>= V.N, == V.*

この演算子は、 ~=1 のように単独の構成部分バージョン番号と一緒に用いてはなりません。

例えば、次に挙げるバージョン番号群はすべて同等ということになります:

~= 2.2
>= 2.2, == 2.*

~= 1.4.5
>= 1.4.5, == 1.4.*

プレリリース、ポストリリース、または開発リリースが V.N.suffix のような互換性のあるリリース節の形の名前を付けられているなら、要求される接頭辞と合致するかどうかを決める時には接尾辞が無視されます:

~= 2.2.post3
>= 2.2.post3, == 2.*

~= 1.4.5a4
>= 1.4.5a4, == 1.4.*

リリース番号構成部分の比較に対するパディングの規則とは、互換性のあるリリース節での前方互換性に想定された度合いを、バージョン識別子の後ろにゼロを追加して制御することが可能です:

~= 2.2.0
>= 2.2.0, == 2.2.*

~= 1.4.5.0
>= 1.4.5.0, == 1.4.5.*

バージョン番号の照合

バージョン番号マッチング節には、バージョン番号マッチング演算子 == とバージョン識別子を含みます。

指定されたバージョン識別子は、 バージョン番号枠組み に記述された標準フォーマットでなければなりませんが、公開のバージョン識別子における後続する .* は以下に述べるように許されています。

デフォルトでは、バージョン番号マッチング演算子は、厳密な同一性の比較です: 指定されたバージョンは、要求されたバージョンと正確に同一でなければなりません。 唯一の 置換が行われるのは、リリース番号構成部分を同じ長さで行うことを保証するために、リリース番号構成部分にゼロをパディングする時だけです。

厳密なバージョンマッチングが適切であるか否かは、バージョン指定子のユースケースによって変わります。自動化されたツール群は、厳密なバージョンマッチングが使用された時には、少なくとも警告を発するべきで、全てを拒絶しても構いません。

バージョンマッチング節のバージョン識別子の末尾に .* を孵化することで、厳密な比較の代わりに接頭辞マッチングが要求されることもあります。これによって、あるバージョン識別子がその節に合致するか否かを決定する時に、追加の後続構成要素を無視することになるでしょう。指定されたバージョン番号がリリース番号構成部分だけを含んでいるなら、リリース番号構成部分の中の後続の構成部分 (あるいは、その欠落) もまた、無視されます。

例えば、あるバージョン番号 1.1.post1 が与えられたとして、以下に示すように合致したり合致しなかったりします:

== 1.1        # Not equal, so 1.1.post1 does not match clause
== 1.1.post1  # Equal, so 1.1.post1 matches clause
== 1.1.*      # Same prefix, so 1.1.post1 matches clause

接頭辞マッチングの目的のためには、プレリリース構成部分は、暗黙の裡に先行する . を持つものと見なされ、従って、バージョン番号 1.1a1 が与えられたとすれば、以下に示すように合致したり合致しなかったりします:

== 1.1        # Not equal, so 1.1a1 does not match clause
== 1.1a1      # Equal, so 1.1a1 matches clause
== 1.1.*      # Same prefix, so 1.1a1 matches clause if pre-releases are requested

正確な合致は、また、接頭辞の合致 (これの解釈は、リリース番号構成部分やバージョン識別子に対する通常のゼロパディングを暗に意味します) であるものと見做されます。バージョン番号 1.1 が与えられたなら、以下に示すように合致したり合致しなかったりします:

== 1.1        # Equal, so 1.1 matches clause
== 1.1.0      # Zero padding expands 1.1 to 1.1.0, so it matches clause
== 1.1.dev1   # Not equal (dev-release), so 1.1 does not match clause
== 1.1a1      # Not equal (pre-release), so 1.1 does not match clause
== 1.1.post1  # Not equal (post-release), so 1.1 does not match clause
== 1.1.*      # Same prefix, so 1.1 matches clause

1.0.dev1. や 1.0foo1.* のような開発リリース番号やローカルリリース番号を含む接頭辞マッチは正当なものではありません。もし存在すれば、開発リリース番号構成部分は常に公開のバージョン番号の最終構成部分であり、ローカルバージョン番号は比較の目的においては無視されるので、そのようなものが接頭辞マッチにあったとしても意味を成しません。

公開された配布物に対する依存関係を定義する時、 (少なくとも接尾辞にワイルドカードを含まないような) == の使用は強い非推奨であり、それはセキュリティフィクスの展開を大きく複雑化させるからです。厳密なバージョン比較演算子は、一義的に、共有の配布物インデックスを使う上で繰り返し可能な アプリケーションの展開 のための依存関係を定義するために使われることを想定しています。

指定されたバージョン識別子は (ローカルバージョン番号ラベルなしの) 公開バージョン識別子であり、候補バージョンに付けられたローカルバージョン番号ラベルは、バージョンマッチングの際には無視されなければなりません。

指定されたバージョン識別子がローカルバージョン識別子であるなら、バージョン間のマッチングでは、候補バージョンのローカルバージョンラベルは上記の通り公開バージョン識別子と合致するか確かめられ、ローカルバージョンラベルは厳密な文字列の同一性比較を使って同一であるかどうか確認されます。

バージョンの除外 <Version exclusion>

バージョンの除外節は、バージョン除外演算子 != とバージョン識別子を含みます。

許されるバージョン識別子と比較のセマンティックスは、マッチの意味が反転している点を除けば バージョン番号のマッチング 演算子のそれと同一です。

例えば、あるバージョン番号 1.1.post1 が与えられたとして、以下に示すように合致したり合致しなかったりします:

!= 1.1        # Not equal, so 1.1.post1 matches clause
!= 1.1.post1  # Equal, so 1.1.post1 does not match clause
!= 1.1.*      # Same prefix, so 1.1.post1 does not match clause

境界を含む順序比較 <Inclusive ordered comparison>

境界を含む順序比較節は比較演算子とバージョン識別子を含み、候補バージョンの相対的な位置と指定されたバージョンに対して与えられる標準の バージョン番号枠組み によって定義される首尾一貫した順序付けに基づいてその比較が正しいかどうかを任意のバージョン番号に対して行います。

境界を含む順序比較の演算子は <= と >= です。

バージョン番号のマッチングと同様に、リリース番号構成部分が同じ長さで比較されることを担保するために、リリース番号構成部分は必要に応じてゼロでパディングされます。

ローカルバージョン識別子は、このバージョン識別子の中では許されません。

境界を含まない順序比較 <Exclusive ordered comparison>

境界を含まない順序比較である > と < は、標準の バージョン番号枠組み によって定義される首尾一貫した順序付けが与える候補バージョンと指定されたバージョン番号の相対的な位置に依存する点で、境界を含む順序比較と似ています。しかしながら、指定されたバージョン番号のプレリリース・ポストリリース・ローカルバージョンの部分を除外します。

境界を含まない順序比較である >V は、V それ自身がポストリリース番号である場合を除いて、与えられたバージョン番号のポストリリース部分を 許してはなりません 。 >V.postN を使うことで、特定のポストリリースバージョンよりも新しいリリースを要求しても構いません。例えば、 >1.7 は 1.7.1 を許容しますが 1.7.0.post1 を許容せず、 >1.7.post2 は 1.7.1 や 1.7.0.post3 を許容しますが 1.7.0 を許容しません。

境界を含まない順序比較 >V は、指定されたバージョン番号のローカルバージョン部分と 比較してはなりません。

境界を含まない順序比較の <V では、指定されたバージョン番号それ自身がプレリリース番号でない限り、指定されたバージョン番号にプレリリース部分が あってはなりません 。 <V.rc1 や同様のものを使えば、指定されたプレリリース番号を含まずにそれより前であるプレリリース番号を許容することができるでしょう。

バージョン番号のマッチングと同様に、リリース番号構成部分が同じ長さで比較されることを担保するために、リリース番号構成部分は必要に応じてゼロでパディングされます。

ローカルバージョン識別子は、このバージョン識別子の中では許されません。

あらゆる意味での同一性 <Arbitrary equality>

あらゆる意味での同一性比較は、ゼロパディングやローカルバージョンのような意味論的な情報を全く考慮しない単純な文字列の同一性演算です。この演算子は、また、 == 演算子なら実行するようなプレフィクスのマッチングもサポートしていません。

あらゆる意味での同一性比較の一義的なユースケースは、これを使わなければこの仕様によって表現され得ないようなバージョン番号を指定することを許容するということです。この演算子は特別で、誰かがこの仕様を実装したツールを使って、さもなければこの仕様とは非互換になってしまうようなレガシーなバージョンを、それでもインストールすることができる脱出ハッチとして振舞います。

一つの例としては、foobar というバージョン番号に合致するであろう ==foobar ということになるでしょう。

この演算子は、また、 1.0+downstream1 のようなバージョンに合致しないであろうと思われる、 ===1.0 のようなプロジェクトのパッチ適用のないバージョンを明示的に要求するためにも使われます。

この演算子の使用は強い非推奨の状態にあり、使用に際してはツール類は警告を表示しても構いません。

プレリリースの取り扱い <Handling of pre-releases>

すでにシステム上に存在しているか、ユーザによって明示的に要求されるか、または、バージョン指定子を満足する唯一の利用可能なバージョンがプレリリースであるか、の いずれかでない限り 、開発リリースを含むプレリリースは、どんな種類でも、あらゆるバージョン指定子から暗黙裡に除外されます。

デフォルトでは、依存関係を解決しようとするツール類は以下のことを行うべきです:

• 全てのバージョン指定子向けにすでにインストールされているプレリリースを受け入れる

• バージョン指定子を満足するような最終リリースやポストリリースが存在しないリモートサイトにあって利用可能なプレリリースを、バージョン指定子として受け入れる

• 他のすべてのプレリリースを考慮の対象から除外する

依存関係解決ツール群は、バージョン指定子を満足させるためにあるプレリリースが必要である場合には、警告を発しても構いません。

依存関係解決ツール群は、また、以下のような代替的な振る舞いをユーザが要求することを許容するべきです:

• 全てのバージョン指定子にプレリリースを受け入れること

• 全てのバージョン指定子からプレリリースを除外すること (プレリリースがすでにローカルにインストールされている場合や特定の指定子を満たすためにはプレリリースが唯一の選択肢である場合には、エラーないし警告を報告すること)

依存関係解決ツール群は、配布物の単位ごとに上記の振る舞いを許容しても構いません。

ポストリリースと最終リリースは、バージョン識別子の中で何ら特別な取り扱いを受けません - 明示的に除外されていない限り、これらは常に受け入れられます。

例

• ~=3.1: バージョン 3.1 またはそれ以降、しかし、バージョン 4.0 またはそれ以降ではない。

• ~=3.1.2: バージョン 3.1.2 またはそれ以降、しかし、バージョン 3.2.0 またはそれ以降ではない。

• ~=3.1a1: バージョン 3.1a1 またはそれ以降、しかし、バージョン 4.0 またはそれ以降ではない。

• == 3.1: 正確にバージョン 3.1 (または 3.1.0)、プレリリース・ポストリリース・開発リリースや 3.1.x のメンテナンスリリースは全て除外する。

• == 3.1.*: 3.1 で始まるすべてのバージョン。 ~=3.1.0 互換リリース節に同じ。

• ~=3.1.0, != 3.1.3: バージョン 3.1.0 またはそれ以降、しかし、バージョン 3.1.3 ではなく、バージョン 3.2.0 またはそれ以降でもない。

直接参照

自動化ツールの中には、通常のバージョン指定子の代替として直接参照の使用を許すものがあります。直接参照は、それを指定する @ と明示された URL から構成されます。

直接参照が適切であるか否かは、バージョン指定子に対する特定のユースケースに依存します。自動化ツール群は、少なくとも警告を発行するべきで、直接参照が不適切に使われた場合には全体を拒否しても構いません。

公開のインデックスサーバは、アップロードされた配布物中での直接参照の使用を許すべきではありません。直接参照は、公開者 <publishers> 向けではなくてソフトウェアインテグレータ向けのツールとして意図されたものです。

ユースケースに依存しますが、 URL の直接参照の適切な使い所は sdist や wheel のバイナリアーカイブでしょう。正確な URL やターゲットのサポートがあるかどうかはツール次第です。

例えば、ローカルのソースコードアーカイブが直接に参照されるかもしれません:

pip @ file:///localbuilds/pip-1.3.1.zip

あるいは、ビルド済みのアーカイブが参照されるかもしれません:

pip @ file:///localbuilds/pip-1.3.1-py33-none-any.whl

ローカルにあるファイルを指す URL への参照ではない直接参照は、すべて、 (https のような) 安全な転送メカニズムを指定するべきであり、かつ、検証の目的で URL の中に期待されるハッシュ値を含むべきです。直接参照でハッシュ値の情報が含まれていなかったりツールが理解できないハッシュ値の情報が含まれていたり、採用されているハッシュアルゴリズムが信頼するには弱すぎるとツールが判断したりした場合には、自動化ツールは少なくとも警告を発するべきであり、その URL に依存することを拒否しても構いません。もしそのような直接参照が安全でない転送手段を使っているなら、自動化ツールはその URL に依存するべきではありません。

ソースコードアーカイブのハッシュ値計算には、標準ライブラリの hashlib モジュールの最新版が無条件に提供するハッシュだけを用いることを推奨します。本文書の執筆時点では、 'md5' ・ 'sha1' ・ 'sha224' ・ 'sha256' ・ 'sha384' ・ 'sha512' が該当します。

ソースコードアーカイブと wheel を参照するためには、期待されるハッシュ値は URL の一部として <hash-algorithm>=<expected-hash> エントリに含まれる形で指定されるでしょう。

バージョンコントロールの参照のためには、バージョン管理システムと安全な転送手段の両方を特定するために VCS+プロトコル の書き方が使われるべきで、ハッシュ値で表現したコミット識別子を伴ったバージョン管理システムが使われるべきです。自動化ツール群は、ハッシュ値で表したコミット識別子を持たないバージョン管理システムではハッシュ値がなくても警告を省略しても構いません。

コミットやタグへの参照を URL 内に直接書くことをサポートしないバージョン管理システムを扱うためには、 そのような情報は、 @<コミットのハッシュ値> や @<タグ>#<コミットのハッシュ値> という表記方法を用いて URL の末尾に追加しても構いません。

注釈

これは、 pip がサポートするような既存の VCS 参照の表記方法とは 非常に 異なります。第一に、配布物の名称が URL の一部として埋め込まれるのではなく、前方に移動しています。第二に、タグに基づいて取得する場合であっても、 (特定のタグを伴う悪意あるリポジトリを作成することは容易で、特定の ハッシュ値 を伴うものはより困難であることから) 偽造をより困難にするために あらゆる リンクにハッシュ値が含まれているべきであるという要求に従うために、コミットのハッシュ値が含まれています。

リモート URL の例:

pip @ https://github.com/pypa/pip/archive/1.3.1.zip#sha1=da9234ee9982d4bbb3c72346a6de940a148ea686
pip @ git+https://github.com/pypa/pip.git@7921be1537eac1e97bc40179a57f0349c2aee67d
pip @ git+https://github.com/pypa/pip.git@1.3.1#7921be1537eac1e97bc40179a57f0349c2aee67d

ファイルを指す URL 群

ファイル URL は、 file://<host>/<path> の形を取ります。 <host> が省略された場合は localhost であるものと想定され、 <host> が省略された場合であってさえも３個目のスラッシュが存在していなければなりません。 <path> は、これからアクセスされるであろうファイルシステム上のファイルパスです。

さまざまな *nix オペレーティングシステムでは、 <host> に許される唯一の値は、省略時の localhost か、現在のマシーンが自分自身であると信じている別の FQDN です。換言すれば、 *nix 上では、ローカルマシン上のパスにアクセスするための file:// スキームだけが使用可能であるということです。

Windows では、ファイルフォーマットは、もし可能なら (例えば file:///c:/path/to/a/file のように) <path> の一部としてドライブレターを含んでいるべきです。 *nix とは異なり、 Windows 上では <host> パラメータは、ネットワーク共有上にあるファイルを指定するために使われます。換言すれば、 \\machine\volume\file を file:// url に翻訳するために、最終的に file://machine/volume/file の形になるでしょう。Windows における file:// URL についてもっと詳しい情報を知るためには、 MSDN を見てください。

pkg_resources.parse_version からの相違点のまとめ

• Note: this comparison is to pkg_resources.parse_version as it existed at the time PEP 440 was written. After the PEP was accepted, setuptools 6.0 and later versions adopted the behaviour described here.

• ローカルバージョンの順序付けは異なっていて、この仕様では、ローカルバージョンなしの同バージョンのものよりも後に来るものとして順序付けを行うように要求していますが、他方で、 pkg_resources.parse_version はそれ (訳註、ローカルバージョン) をプレリリースのマーカーの一つであると見做しています。

• この仕様では、正当なバージョン番号を構成する文法を意図的に制限していますが、他方で pkg_resources.parse_version では あらゆる 任意の文字列から何らかの意味を汲み取るように試みます。

• pkg_resources.parse_version では、 1.0.dev1.post1.dev5 のように任意に深く入れ子になったバージョン番号の記号表現を許容します。しかし、この仕様では、それぞれのタイプが高々一度だけ使われることと、ある順番に従って存在していることを許容しているだけです。

補遺: 正規表現を伴うバージョン文字列を解析する

公的バージョン識別子 節で述べられているように、公開されたバージョン識別子は、正統な書式を使用するべきです。この説では、あるバージョン番号が既にその書式に従っているか否かをテストするために使うことができ、そして、もし否であればその後の標準化のためにさまざまな構成要素を引き出すために使うことができる、そのような正規表現を提供します。

バージョン識別子が正統な書式であるか否かを確かめるためには、次の関数を使うことができます:

import re
def is_canonical(version):
    return re.match(r'^([1-9][0-9]*!)?(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*))*((a|b|rc)(0|[1-9][0-9]*))?(\.post(0|[1-9][0-9]*))?(\.dev(0|[1-9][0-9]*))?$', version) is not None

バージョン識別子の構成部分を取り出すためには、以下の正規表現を使ってください (パッケージング プロジェクトによって定義されたもの):

VERSION_PATTERN = r"""
    v?
    (?:
        (?:(?P<epoch>[0-9]+)!)?                           # epoch
        (?P<release>[0-9]+(?:\.[0-9]+)*)                  # release segment
        (?P<pre>                                          # pre-release
            [-_\.]?
            (?P<pre_l>(a|b|c|rc|alpha|beta|pre|preview))
            [-_\.]?
            (?P<pre_n>[0-9]+)?
        )?
        (?P<post>                                         # post release
            (?:-(?P<post_n1>[0-9]+))
            |
            (?:
                [-_\.]?
                (?P<post_l>post|rev|r)
                [-_\.]?
                (?P<post_n2>[0-9]+)?
            )
        )?
        (?P<dev>                                          # dev release
            [-_\.]?
            (?P<dev_l>dev)
            [-_\.]?
            (?P<dev_n>[0-9]+)?
        )?
    )
    (?:\+(?P<local>[a-z0-9]+(?:[-_\.][a-z0-9]+)*))?       # local version
"""

_regex = re.compile(
    r"^\s*" + VERSION_PATTERN + r"\s*$",
    re.VERBOSE | re.IGNORECASE,
)

歴史

• 2014年8月: PEP 440 を通じてこの仕様が承認された。