Öffentliche Versionskennungen

Die kanonischen öffentlichen Versionskennungen MÜSSEN dem folgenden Schema entsprechen

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

Öffentliche Versionskennungen DÜRFEN KEINE führenden oder nachfolgenden Leerzeichen enthalten.

Öffentliche Versionskennungen MÜSSEN innerhalb einer gegebenen Distribution eindeutig sein.

Installation Tools SOLLTEN alle öffentlichen Versionen ignorieren, die diesem Schema nicht entsprechen, MÜSSEN aber auch die unten angegebenen Normalisierungen einschließen. Installation Tools KÖNNEN den Benutzer warnen, wenn nicht konforme oder mehrdeutige Versionen erkannt werden.

Siehe auch Anhang B : Parsen von Versionszeichenfolgen mit regulären Ausdrücken, das einen regulären Ausdruck zur Prüfung der strikten Konformität mit dem kanonischen Format sowie einen permissiveren regulären Ausdruck, der Eingaben akzeptiert, die eine anschließende Normalisierung erfordern können, bereitstellt.

Öffentliche Versionskennungen werden in bis zu fünf Segmente unterteilt

• Epoch-Segment: N!
• Release-Segment: N(.N)*
• Vorab-Release-Segment: {a|b|rc}N
• Nachveröffentlichungs-Segment: .postN
• Entwicklungs-Release-Segment: .devN

Jede gegebene Veröffentlichung ist eine „finale Veröffentlichung“, „Vorab-Veröffentlichung“, „Nachveröffentlichung“ oder „Entwicklungsveröffentlichung“, wie in den folgenden Abschnitten definiert.

Alle numerischen Komponenten MÜSSEN nicht-negative Ganzzahlen sein, die als Sequenzen von ASCII-Ziffern dargestellt werden.

Alle numerischen Komponenten MÜSSEN nach ihrem numerischen Wert und nicht als Textzeichenfolgen interpretiert und sortiert werden.

Alle numerischen Komponenten KÖNNEN Null sein. Mit Ausnahme der unten für das Release-Segment beschriebenen Fälle hat eine numerische Komponente von Null keine besondere Bedeutung, außer dass sie immer der niedrigste mögliche Wert in der Versionsreihenfolge ist.

Lokale Versionskennungen

Lokale Versionskennungen MÜSSEN dem folgenden Schema entsprechen

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

Sie bestehen aus einer normalen öffentlichen Versionskennung (wie im vorherigen Abschnitt definiert) zusammen mit einem beliebigen „lokalen Versions-Label“, getrennt von der öffentlichen Versionskennung durch ein Pluszeichen. Lokale Versions-Labels haben keine spezifische Semantik, aber es werden einige syntaktische Einschränkungen auferlegt.

Lokale Versionskennungen werden verwendet, um vollständig API- (und ggf. ABI-) kompatible gepatchte Versionen von Upstream-Projekten zu bezeichnen. Zum Beispiel können diese von Anwendungsentwicklern und Systemintegratoren durch Anwendung spezifischer zurückportierter Fehlerbehebungen erstellt werden, wenn ein Upgrade auf eine neue Upstream-Version zu störend für die Anwendung oder das andere integrierte System (wie eine Linux-Distribution) wäre.

Die Einbeziehung des lokalen Versions-Labels ermöglicht es, Upstream-Veröffentlichungen von potenziell geänderten Neukompilierungen durch Downstream-Integratoren zu unterscheiden. Die Verwendung einer lokalen Versionskennung hat keinen Einfluss auf die Art einer Veröffentlichung, aber wenn sie auf eine Quellverteilung angewendet wird, zeigt sie an, dass sie möglicherweise nicht genau denselben Code wie die entsprechende Upstream-Veröffentlichung enthält.

Um sicherzustellen, dass lokale Versionskennungen leicht als Teil von Dateinamen und URLs aufgenommen werden können und um Formatierungskonsistenz in hexadezimalen Hash-Darstellungen zu vermeiden, MÜSSEN lokale Versions-Labels auf die folgende Menge von zulässigen Zeichen beschränkt sein

• ASCII-Buchstaben ([a-zA-Z])
• ASCII-Ziffern ([0-9])
• Punkte (.)

Lokale Versions-Labels MÜSSEN mit einem ASCII-Buchstaben oder einer Ziffer beginnen und enden.

Der Vergleich und die Sortierung lokaler Versionen berücksichtigen jedes Segment des lokalen Versions-Labels (geteilt durch einen Punkt .) separat. Wenn ein Segment ausschließlich aus ASCII-Ziffern besteht, wird dieser Abschnitt für Vergleichszwecke als Ganzzahl betrachtet. Wenn ein Segment ASCII-Buchstaben enthält, wird dieses Segment lexikografisch und unabhängig von der Groß-/Kleinschreibung verglichen. Beim Vergleich eines numerischen und eines lexikografischen Segments ist das numerische Segment immer größer als das lexikografische Segment. Darüber hinaus ist eine lokale Version mit einer größeren Anzahl von Segmenten immer größer als eine lokale Version mit weniger Segmenten, solange die kürzeren lokalen Versionssegmente exakt mit dem Anfang der längeren lokalen Versionssegmente übereinstimmen.

Ein „Upstream-Projekt“ ist ein Projekt, das seine eigenen öffentlichen Versionen definiert. Ein „Downstream-Projekt“ ist eines, das ein Upstream-Projekt verfolgt und neu verteilt und möglicherweise Sicherheits- und Fehlerkorrekturen aus späteren Versionen des Upstream-Projekts zurückportiert.

Lokale Versionskennungen SOLLTEN nicht bei der Veröffentlichung von Upstream-Projekten auf einem öffentlichen Index-Server verwendet werden, KÖNNEN aber zur Identifizierung privater Builds verwendet werden, die direkt aus dem Quellcode des Projekts erstellt wurden. Lokale Versionskennungen SOLLTEN von Downstream-Projekten verwendet werden, wenn eine Version veröffentlicht wird, die API-kompatibel mit der Version des Upstream-Projekts ist, die durch die öffentliche Versionskennung identifiziert wird, aber zusätzliche Änderungen (wie Fehlerbehebungen) enthält. Da der Python Package Index ausschließlich für die Indizierung und das Hosting von Upstream-Projekten bestimmt ist, DARF er die Verwendung lokaler Versionskennungen NICHT zulassen.

Quellverteilungen, die eine lokale Versionskennung verwenden, SOLLTEN die Erweiterungsmetadaten python.integrator (wie in PEP 459 definiert) bereitstellen.

Finale Veröffentlichungen

Eine Versionskennung, die ausschließlich aus einem Release-Segment und optional einer Epoch-Kennung besteht, wird als „finale Veröffentlichung“ bezeichnet.

Das Release-Segment besteht aus einem oder mehreren nicht-negativen ganzzahligen Werten, die durch Punkte getrennt sind

N(.N)*

Finale Veröffentlichungen innerhalb eines Projekts MÜSSEN in einer konsistent steigenden Reihenfolge nummeriert werden, andernfalls können automatisierte Werkzeuge sie nicht korrekt aktualisieren.

Der Vergleich und die Sortierung von Release-Segmenten berücksichtigen der Reihe nach den numerischen Wert jeder Komponente des Release-Segments. Beim Vergleichen von Release-Segmenten mit unterschiedlicher Anzahl von Komponenten wird das kürzere Segment nach Bedarf mit zusätzlichen Nullen aufgefüllt.

Obwohl unter diesem Schema eine beliebige Anzahl von zusätzlichen Komponenten nach der ersten zulässig ist, sind die gängigsten Varianten die Verwendung von zwei Komponenten („major.minor“) oder drei Komponenten („major.minor.micro“).

Zum Beispiel:

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
...

Eine Release-Serie ist jede Menge von finalen Release-Nummern, die mit einem gemeinsamen Präfix beginnen. Zum Beispiel sind 3.3.1, 3.3.5 und 3.3.9.45 alle Teil der 3.3-Release-Serie.

Datumsbasierte Release-Segmente sind ebenfalls zulässig. Ein Beispiel für ein datumsbasiertes Release-Schema, das Jahr und Monat der Veröffentlichung verwendet

2012.4
2012.7
2012.10
2013.1
2013.6
...

Vorab-Veröffentlichungen

Einige Projekte verwenden einen „Alpha-, Beta-, Release-Candidate“-Vorab-Release-Zyklus, um die Tests durch ihre Benutzer vor einer finalen Veröffentlichung zu unterstützen.

Wenn diese Vorab-Veröffentlichungen als Teil des Entwicklungszyklus eines Projekts verwendet werden, werden sie durch die Einbeziehung eines Vorab-Release-Segments in die Versionskennung angezeigt

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

Eine Versionskennung, die ausschließlich aus einem Release-Segment und einem Vorab-Release-Segment besteht, wird als „Vorab-Veröffentlichung“ bezeichnet.

Das Vorab-Release-Segment besteht aus einer alphabetischen Kennung für die Vorab-Release-Phase zusammen mit einem nicht-negativen ganzzahligen Wert. Vorab-Veröffentlichungen für eine gegebene Veröffentlichung werden zuerst nach Phase (Alpha, Beta, Release Candidate) und dann nach der numerischen Komponente innerhalb dieser Phase geordnet.

Installation Tools KÖNNEN sowohl c als auch rc-Veröffentlichungen für ein gemeinsames Release-Segment akzeptieren, um einige bestehende Legacy-Distributionen zu handhaben.

Installation Tools SOLLTEN c-Versionen als äquivalent zu rc-Versionen interpretieren (d. h. c1 bezeichnet dieselbe Version wie rc1).

Build-Tools, Publication Tools und Index-Server SOLLTEN die Erstellung sowohl von rc- als auch von c-Veröffentlichungen für ein gemeinsames Release-Segment verbieten.

Nachveröffentlichungen

Einige Projekte verwenden Nachveröffentlichungen, um kleinere Fehler in einer finalen Veröffentlichung zu beheben, die die verteilte Software nicht beeinflussen (z. B. die Korrektur eines Fehlers in den Release Notes).

Wenn diese Nachveröffentlichungen als Teil des Entwicklungszyklus eines Projekts verwendet werden, werden sie durch die Einbeziehung eines Nachveröffentlichungs-Segments in die Versionskennung angezeigt

X.Y.postN    # Post-release

Eine Versionskennung, die ein Nachveröffentlichungs-Segment ohne ein Entwicklungs-Release-Segment enthält, wird als „Nachveröffentlichung“ bezeichnet.

Das Nachveröffentlichungs-Segment besteht aus der Zeichenkette .post, gefolgt von einem nicht-negativen ganzzahligen Wert. Nachveröffentlichungen werden nach ihrer numerischen Komponente geordnet, unmittelbar nach der entsprechenden Veröffentlichung und vor jeder nachfolgenden Veröffentlichung.

Nachveröffentlichungen sind auch für Vorab-Veröffentlichungen zulässig

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

Entwicklungsveröffentlichungen

Einige Projekte erstellen regelmäßige Entwicklungsversionen, und Systempaketierer (insbesondere für Linux-Distributionen) möchten möglicherweise frühe Versionen direkt aus der Quellcodeverwaltung erstellen, die nicht mit späteren Projektversionen kollidieren.

Wenn diese Entwicklungsversionen als Teil des Entwicklungszyklus eines Projekts verwendet werden, werden sie durch die Einbeziehung eines Entwicklungs-Release-Segments in die Versionskennung angezeigt

X.Y.devN    # Developmental release

Eine Versionskennung, die ein Entwicklungs-Release-Segment enthält, wird als „Entwicklungsversion“ bezeichnet.

Das Entwicklungs-Release-Segment besteht aus der Zeichenkette .dev, gefolgt von einem nicht-negativen ganzzahligen Wert. Entwicklungsversionen werden nach ihrer numerischen Komponente geordnet, unmittelbar vor der entsprechenden Veröffentlichung (und vor allen Vorab-Veröffentlichungen mit demselben Release-Segment) und nach jeder vorherigen Veröffentlichung (einschließlich Nachveröffentlichungen).

Entwicklungsversionen sind auch für Vorab-Veröffentlichungen und Nachveröffentlichungen zulässig

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

Versionsepochen

Wenn eine Epoch in einer Versionskennung enthalten ist, erscheint sie vor allen anderen Komponenten, getrennt vom Release-Segment durch ein Ausrufezeichen

E!X.Y  # Version identifier with epoch

Wenn keine explizite Epoch angegeben ist, ist die implizite Epoch 0.

Die meisten Versionskennungen werden keine Epoch enthalten, da eine explizite Epoch nur benötigt wird, wenn ein Projekt die Art und Weise, wie es Versionen nummeriert, *ändert*, sodass die normalen Versionssortierregeln das falsche Ergebnis liefern. Zum Beispiel, wenn ein Projekt datumsbasierte Versionen wie 2014.04 verwendet und zu semantischen Versionen wie 1.0 wechseln möchte, dann werden die neuen Veröffentlichungen als *älter* als die datumsbasierten Veröffentlichungen betrachtet, wenn das normale Sortierschema verwendet wird

1.0
1.1
2.0
2013.10
2014.04

Durch die Angabe einer expliziten Epoch kann die Sortierreihenfolge jedoch entsprechend geändert werden, da alle Versionen aus einer späteren Epoch nach Versionen aus einer früheren Epoch sortiert werden

2013.10
2014.04
1!1.0
1!1.1
1!2.0

Normalisierung

Um eine bessere Kompatibilität mit bestehenden Versionen zu gewährleisten, gibt es eine Reihe von „alternativen“ Syntaxes, die bei der Interpretation von Versionen berücksichtigt werden MÜSSEN. Diese Syntaxes MÜSSEN bei der Interpretation einer Version berücksichtigt werden, sie sollten jedoch in die oben definierte Standard-Syntax „normalisiert“ werden.

Beispiele für konforme Versionsschemata

Das Standard-Versionsschema ist darauf ausgelegt, eine breite Palette von Identifizierungspraktiken in öffentlichen und privaten Python-Projekten abzudecken. In der Praxis würde ein einzelnes Projekt, das versucht, die volle Flexibilität des Schemas zu nutzen, eine Situation schaffen, in der menschliche Benutzer Schwierigkeiten hätten, die relative Reihenfolge der Versionen zu ermitteln, obwohl die oben genannten Regeln sicherstellen, dass alle konformen Werkzeuge sie konsistent sortieren werden.

Die folgenden Beispiele veranschaulichen eine kleine Auswahl der verschiedenen Ansätze, die Projekte zur Identifizierung ihrer Releases wählen können, während gleichzeitig sichergestellt wird, dass die „neueste Version“ und die „neueste stabile Version“ sowohl für menschliche Benutzer als auch für automatisierte Werkzeuge leicht ermittelt werden können.

Einfache „Major.Minor“-Versionsverwaltung

0.1
0.2
0.3
1.0
1.1
...

Einfache „Major.Minor.Micro“-Versionsverwaltung

1.1.0
1.1.1
1.1.2
1.2.0
...

„Major.Minor“-Versionsverwaltung mit Alpha-, Beta- und Candidate-Vorabversionen

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

„Major.Minor“-Versionsverwaltung mit Entwicklungsversionen, Release-Kandidaten und Post-Releases für kleinere Korrekturen

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
...

Datumsbasierte Releases mit fortlaufender Seriennummer pro Jahr, wobei Null übersprungen wird

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

Zusammenfassung der zulässigen Suffixe und relative Reihenfolge

Das Epoch-Segment von Versionsbezeichnern MUSS entsprechend dem numerischen Wert des gegebenen Epoch sortiert werden. Wenn kein Epoch-Segment vorhanden ist, ist der implizite numerische Wert 0.

Das Release-Segment von Versionsbezeichnern MUSS in derselben Reihenfolge sortiert werden wie die Tupelsortierung von Python, wenn das normalisierte Release-Segment wie folgt geparst wird

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

Alle beteiligten Release-Segmente MÜSSEN durch Auffüllen kürzerer Segmente mit Nullen auf eine konsistente Länge umgewandelt werden.

Innerhalb eines numerischen Releases (1.0, 2.7.3) sind die folgenden Suffixe zulässig und MÜSSEN wie gezeigt geordnet werden

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

Beachten Sie, dass c semantisch äquivalent zu rc ist und so sortiert werden muss, als wäre es rc. Werkzeuge DÜRFEN den Fall, dass derselbe N sowohl für ein c als auch für ein rc im selben Release-Segment vorkommt, als missverständlich ablehnen und weiterhin mit der PEP konform bleiben.

Innerhalb eines Alpha (1.0a1), Beta (1.0b1) oder Release Candidate (1.0rc1, 1.0c1) sind die folgenden Suffixe zulässig und MÜSSEN wie gezeigt geordnet werden

.devN, <no suffix>, .postN

Innerhalb eines Post-Releases (1.0.post1) sind die folgenden Suffixe zulässig und MÜSSEN wie gezeigt geordnet werden

.devN, <no suffix>

Beachten Sie, dass devN und postN IMMER einem Punkt vorangestellt sein MÜSSEN, auch wenn sie unmittelbar nach einer numerischen Version verwendet werden (z. B. 1.0.dev456, 1.0.post1).

Innerhalb eines Vorab-, Post- oder Entwicklungsrelease-Segments mit einem gemeinsamen Präfix muss die Sortierung nach dem Wert der numerischen Komponente erfolgen.

Das folgende Beispiel deckt viele der möglichen Kombinationen ab

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

Versionsreihenfolge über verschiedene Metadatenversionen hinweg

Metadaten v1.0 (PEP 241) und Metadaten v1.1 (PEP 314) definieren kein standardisiertes Versionsidentifikations- oder Sortierungsschema. Metadaten v1.2 (PEP 345) definieren jedoch ein Schema, das in PEP 386 festgelegt ist.

Aufgrund der Natur der einfachen Installer-API ist es einem Installer nicht möglich, zu wissen, welche Metadatenversion eine bestimmte Distribution verwendet hat. Zusätzlich benötigten Installer die Möglichkeit, eine vernünftig priorisierte Liste zu erstellen, die alle, oder so viele wie möglich, Versionen eines Projekts enthält, um festzustellen, welche Versionen installiert werden sollten. Diese Anforderungen machen eine Standardisierung eines einzigen Parsing-Mechanismus für alle Versionen eines Projekts notwendig.

Aus den oben genannten Gründen MUSS diese PEP für alle Metadatenversionen verwendet werden und ersetzt PEP 386, auch für Metadaten v1.2. Werkzeuge SOLLTEN alle Versionen ignorieren, die nicht nach den Regeln dieser PEP geparst werden können, DÜRFEN aber auf implementierungsdefinierte Version-Parsing- und Sortierungsschemata zurückgreifen, wenn keine Versionen verfügbar sind, die mit dieser PEP konform sind.

Distributionsbenutzer möchten möglicherweise nicht konforme Versionen aus privaten Paketindizes, die sie kontrollieren, explizit entfernen.

Kompatibilität mit anderen Versionsschemata

Einige Projekte entscheiden sich möglicherweise für ein Versionsschema, das eine Übersetzung erfordert, um dem öffentlichen Versionsschema, das in dieser PEP definiert ist, zu entsprechen. In solchen Fällen können die projektspezifische Version in den Metadaten gespeichert und die übersetzte öffentliche Version im Versionsfeld veröffentlicht werden.

Dies ermöglicht es automatisierten Distributionswerkzeugen, eine konsistent korrekte Sortierung veröffentlichter Releases bereitzustellen, während Entwickler weiterhin das interne Versionsschema verwenden können, das sie für ihre Projekte bevorzugen.

Kompatible Veröffentlichung

Eine kompatible Release-Klausel besteht aus dem Operator für kompatible Releases ~= und einem Versionsbezeichner. Sie entspricht jeder Kandidatenversion, die als kompatibel mit der angegebenen Version angesehen wird.

Der angegebene Versionsbezeichner muss im Standardformat gemäß Versionsschema vorliegen. Lokale Versionsbezeichner sind in diesem Versionsspezifikator NICHT zulässig.

Für einen gegebenen Release-Bezeichner V.N ist die kompatible Release-Klausel annähernd äquivalent zum Paar von Vergleichsklauseln

>= V.N, == V.*

Dieser Operator darf NICHT mit einer Versionsnummer mit nur einem Segment verwendet werden, wie z. B. ~=1.

Zum Beispiel sind die folgenden Gruppen von Versionsklauseln äquivalent

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

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

Wenn ein Vorab-, Post- oder Entwicklungsrelease in einer kompatiblen Release-Klausel als V.N.suffix benannt wird, wird das Suffix bei der Bestimmung des erforderlichen Präfix-Abgleichs ignoriert.

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

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

Die Auffüllregeln für Vergleiche von Release-Segmenten bedeuten, dass der angenommene Grad der Vorwärtskompatibilität in einer kompatiblen Release-Klausel durch Anhängen zusätzlicher Nullen an den Versionsspezifikator gesteuert werden kann.

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

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

Versionsabgleich

Eine Versionsabgleich-Klausel enthält den Versionsabgleich-Operator == und einen Versionsbezeichner.

Der angegebene Versionsbezeichner muss im Standardformat gemäß Versionsschema vorliegen, aber ein nachgestelltes .* ist bei öffentlichen Versionsbezeichnern zulässig, wie unten beschrieben.

Standardmäßig basiert der Versionsabgleich-Operator auf einem strikten Gleichheitsvergleich: Der angegebene Versionsbezeichner muss exakt mit der angeforderten Version übereinstimmen. Die *einzige* durchgeführte Ersetzung ist die Nullauffüllung des Release-Segments, um sicherzustellen, dass die Release-Segmente mit der gleichen Länge verglichen werden.

Ob ein strikter Versionsabgleich angemessen ist, hängt vom spezifischen Anwendungsfall des Versionsspezifikators ab. Automatisierte Werkzeuge SOLLTEN mindestens Warnungen ausgeben und DÜRFEN sie vollständig ablehnen, wenn strikte Versionsabgleiche unangemessen verwendet werden.

Anstelle eines strikten Vergleichs kann ein Präfix-Abgleich angefordert werden, indem ein nachgestelltes .* an den Versionsbezeichner in der Versionsabgleich-Klausel angehängt wird. Das bedeutet, dass zusätzliche nachgestellte Segmente ignoriert werden, wenn bestimmt wird, ob ein Versionsbezeichner die Klausel erfüllt. Wenn die angegebene Version nur ein Release-Segment enthält, werden nachgestellte Komponenten (oder deren Fehlen) im Release-Segment ebenfalls ignoriert.

Zum Beispiel würden bei der Version 1.1.post1 die folgenden Klauseln wie gezeigt übereinstimmen oder nicht

== 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

Für den Präfix-Abgleich wird das Vorabversions-Segment als mit einem impliziten vorangestellten Punkt betrachtet. Bei der Version 1.1a1 würden die folgenden Klauseln wie gezeigt übereinstimmen oder nicht

== 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

Eine exakte Übereinstimmung gilt auch als Präfix-Übereinstimmung (diese Interpretation ist durch die üblichen Nullauffüllregeln für das Release-Segment von Versionsbezeichnern impliziert). Bei der Version 1.1 würden die folgenden Klauseln wie gezeigt übereinstimmen oder nicht

== 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

Es ist ungültig, einen Präfix-Abgleich mit einer Entwicklungs- oder lokalen Version zu haben, wie z. B. 1.0.dev1.* oder 1.0+foo1.*. Falls vorhanden, ist das Entwicklungsrelease-Segment immer das letzte Segment in der öffentlichen Version, und die lokale Version wird für Vergleichszwecke ignoriert, sodass die Verwendung in einem Präfix-Abgleich keinen Sinn ergeben würde.

Die Verwendung von == (ohne mindestens das Wildcard-Suffix) bei der Definition von Abhängigkeiten für veröffentlichte Distributionen wird dringend abgeraten, da sie die Bereitstellung von Sicherheitsupdates erheblich erschwert. Der strikte Versionsvergleichsoperator ist hauptsächlich für die Definition von Abhängigkeiten für wiederholbare *Anwendungsdeployments* bei Verwendung eines gemeinsamen Distributionsindexes vorgesehen.

Wenn der angegebene Versionsbezeichner ein öffentlicher Versionsbezeichner ist (kein lokales Versions-Label), dann MUSS das lokale Versions-Label aller Kandidatenversionen beim Abgleich von Versionen ignoriert werden.

Wenn der angegebene Versionsbezeichner ein lokaler Versionsbezeichner ist, dann MÜSSEN die lokalen Versions-Labels von Kandidatenversionen beim Abgleich von Versionen berücksichtigt werden, wobei der öffentliche Versionsbezeichner wie oben beschrieben abgeglichen wird und das lokale Versions-Label auf Gleichheit mittels strikten Zeichenketten-Gleichheitsvergleichs geprüft wird.

Versionen ausschließen

Eine Versionsausschluss-Klausel enthält den Versionsausschluss-Operator != und einen Versionsbezeichner.

Die zulässigen Versionsbezeichner und Vergleichssemantiken sind dieselben wie die des Versionsabgleichs-Operators, außer dass die Bedeutung jedes Abgleichs invertiert ist.

Zum Beispiel würden bei der Version 1.1.post1 die folgenden Klauseln wie gezeigt übereinstimmen oder nicht

!= 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

Inklusive geordneter Vergleich

Eine inklusive geordnete Vergleichsklausel enthält einen Vergleichsoperator und einen Versionsbezeichner und entspricht jeder Version, bei der der Vergleich korrekt ist, basierend auf der relativen Position der Kandidatenversion und der angegebenen Version gemäß der konsistenten Sortierung, die durch das Standard-Versionsschema definiert ist.

Die inklusiven geordneten Vergleichsoperatoren sind <= und >=.

Wie beim Versionsabgleich wird das Release-Segment nach Bedarf mit Nullen aufgefüllt, um sicherzustellen, dass die Release-Segmente mit der gleichen Länge verglichen werden.

Lokale Versionsbezeichner sind in diesem Versionsspezifikator NICHT zulässig.

Exklusive geordneter Vergleich

Die exklusiven geordneten Vergleiche > und < ähneln den inklusiven geordneten Vergleichen, da sie auf der relativen Position der Kandidatenversion und der angegebenen Version basieren, gemäß der konsistenten Sortierung, die durch das Standard-Versionsschema definiert ist. Sie schließen jedoch ausdrücklich Vorabversionen, Post-Releases und lokale Versionen der angegebenen Version aus.

Der exklusive geordnete Vergleich >V darf KEINE Post-Releases der gegebenen Version zulassen, es sei denn, V ist selbst ein Post-Release. Sie können erzwingen, dass Releases später als ein bestimmtes Post-Release sind, einschließlich zusätzlicher Post-Releases, indem Sie >V.postN verwenden. Zum Beispiel erlaubt >1.7 1.7.1, aber nicht 1.7.0.post1 und >1.7.post2 erlaubt 1.7.1 und 1.7.0.post3, aber nicht 1.7.0.

Der exklusive geordnete Vergleich >V darf KEINE lokale Version der angegebenen Version entsprechen.

Der exklusive geordnete Vergleich <V darf KEINE Vorabversion der angegebenen Version zulassen, es sei denn, die angegebene Version ist selbst eine Vorabversion. Das Zulassen von Vorabversionen, die früher als eine bestimmte Vorabversion sind, aber nicht gleich, kann durch die Verwendung von <V.rc1 oder ähnlichem erreicht werden.

Wie beim Versionsabgleich wird das Release-Segment nach Bedarf mit Nullen aufgefüllt, um sicherzustellen, dass die Release-Segmente mit der gleichen Länge verglichen werden.

Lokale Versionsbezeichner sind in diesem Versionsspezifikator NICHT zulässig.

Beliebige Gleichheit

Beliebige Gleichheitsvergleiche sind einfache Zeichenketten-Gleichheitsoperationen, die keine semantischen Informationen wie Nullauffüllung oder lokale Versionen berücksichtigen. Dieser Operator unterstützt auch keinen Präfix-Abgleich, wie es der Operator == tut.

Der Hauptanwendungsfall für beliebige Gleichheit ist die Ermöglichung der Spezifikation einer Version, die auf andere Weise nicht durch diese PEP dargestellt werden kann. Dieser Operator ist besonders und fungiert als Fluchtweg, um jemandem, der ein Werkzeug verwendet, das diese PEP implementiert, die Installation einer Legacy-Version zu ermöglichen, die ansonsten inkompatibel mit dieser PEP ist.

Ein Beispiel wäre ===foobar, das einer Version von foobar entsprechen würde.

Dieser Operator kann auch verwendet werden, um explizit eine ungepatchte Version eines Projekts zu fordern, wie z. B. ===1.0, was für eine Version 1.0+downstream1 nicht zutreffen würde.

Die Verwendung dieses Operators wird dringend abgeraten und Werkzeuge KÖNNEN eine Warnung anzeigen, wenn er verwendet wird.

Umgang mit Vorab-Veröffentlichungen

Vorabversionen jeglicher Art, einschließlich Entwicklungsversionen, sind von allen Versionsspezifikatoren implizit ausgeschlossen, *es sei denn*, sie sind bereits auf dem System vorhanden, werden vom Benutzer explizit angefordert oder wenn die einzige verfügbare Version, die den Versionsspezifikator erfüllt, eine Vorabversion ist.

Standardmäßig SOLLTEN Abhängigkeitsauflösungswerkzeuge

• bereits installierte Vorabversionen für alle Versionsspezifikatoren akzeptieren
• entfernt verfügbare Vorabversionen für Versionsspezifikatoren akzeptieren, für die keine finale oder Post-Version den Versionsspezifikator erfüllt
• alle anderen Vorabversionen von der Betrachtung ausschließen

Abhängigkeitsauflösungswerkzeuge KÖNNEN eine Warnung ausgeben, wenn eine Vorabversion zur Erfüllung eines Versionsspezifikators benötigt wird.

Abhängigkeitsauflösungswerkzeuge SOLLTEN den Benutzern auch erlauben, die folgenden alternativen Verhaltensweisen anzufordern

• Akzeptieren von Vorabversionen für alle Versionsspezifikatoren
• Ausschließen von Vorabversionen für alle Versionsspezifikatoren (Fehler- oder Warnmeldung, wenn eine Vorabversion lokal bereits installiert ist oder wenn eine Vorabversion die einzige Möglichkeit ist, einen bestimmten Spezifikator zu erfüllen)

Abhängigkeitsauflösungswerkzeuge KÖNNEN auch erlauben, dass das oben genannte Verhalten pro Distribution gesteuert wird.

Post-Releases und finale Releases erhalten keine besondere Behandlung in Versionsspezifikatoren – sie werden immer eingeschlossen, es sei denn, sie werden explizit ausgeschlossen.

Beispiele

• ~=3.1: Version 3.1 oder neuer, aber nicht Version 4.0 oder neuer.
• ~=3.1.2: Version 3.1.2 oder neuer, aber nicht Version 3.2.0 oder neuer.
• ~=3.1a1: Version 3.1a1 oder neuer, aber nicht Version 4.0 oder neuer.
• == 3.1: speziell Version 3.1 (oder 3.1.0), schließt alle Vorabversionen, Post-Releases, Entwicklungsversionen und alle 3.1.x Wartungsreleases aus.
• == 3.1.*: jede Version, die mit 3.1 beginnt. Äquivalent zur kompatiblen Release-Klausel ~=3.1.0.
• ~=3.1.0, != 3.1.3: Version 3.1.0 oder neuer, aber nicht Version 3.1.3 und nicht Version 3.2.0 oder neuer.

Datei-URLs

Datei-URLs haben das Format file://<host>/<pfad>. Wenn der <host> weggelassen wird, wird angenommen, dass es sich um localhost handelt, und selbst wenn der <host> weggelassen wird, MUSS der dritte Schrägstrich immer noch vorhanden sein. Der <pfad> definiert den Dateipfad im Dateisystem, auf den zugegriffen werden soll.

Auf den verschiedenen *nix-Betriebssystemen sind die einzigen zulässigen Werte für <host>, dass er weggelassen wird, localhost oder ein anderer FQDN, den die aktuelle Maschine als ihren eigenen Host betrachtet. Mit anderen Worten, unter *nix kann das file://-Schema nur verwendet werden, um auf Pfade auf dem lokalen Rechner zuzugreifen.

Unter Windows sollte das Dateiformat den Laufwerksbuchstaben, falls zutreffend, als Teil des <pfad> enthalten (z. B. file:///c:/path/to/a/file). Im Gegensatz zu *nix kann unter Windows der <host>-Parameter verwendet werden, um eine Datei auf einem Netzwerkshare anzugeben. Mit anderen Worten, um \\machine\volume\file in eine file://-URL zu übersetzen, würde dies zu file://machine/volume/file führen. Weitere Informationen zu file://-URLs unter Windows finden Sie in MSDN [4].

Änderung des Versionsschemas

Eine wesentliche Änderung am Versionsschema in diesem PEP im Vergleich zu PEP 386 besteht darin, entwicklungsrelevante Releases auf oberster Ebene wie X.Y.devN vor Alpha-Releases wie X.Ya1 zu sortieren. Dies ist eine weitaus logischere Sortierreihenfolge, da Projekte, die sowohl Entwicklungsreleases als auch Alphas/Betas/Release Candidates verwenden, nicht möchten, dass ihre Entwicklungsreleases zwischen ihren Release Candidates und ihren endgültigen Releases sortiert werden. Es gibt keine Begründung dafür, dev-Releases an dieser Stelle zu verwenden, anstatt lediglich zusätzliche Release Candidates zu erstellen.

Die aktualisierte Sortierreihenfolge bedeutet auch, dass die Sortierung von dev-Versionen nun konsistent zwischen dem Metadatenstandard und dem vorbestehenden Verhalten von pkg_resources (und damit dem Verhalten aktueller Installationstools) ist.

Diese Änderung sollte es für betroffene bestehende Projekte einfacher machen, auf die neueste Version des Metadatenstandards zu migrieren.

Eine weitere Änderung am Versionsschema ist die Zulassung von Einzelnummer-Versionen, ähnlich denen, die von Nicht-Python-Projekten wie Mozilla Firefox, Google Chrome und der Fedora Linux-Distribution verwendet werden. Dies wird tatsächlich voraussichtlich nützlicher für Versionsspezifizierer sein, aber es ist einfacher, es sowohl für Versionsspezifizierer als auch für Release-Nummern zuzulassen, anstatt die beiden Definitionen zu trennen.

Der Ausschluss von führenden und nachgestellten Leerzeichen wurde explizit gemacht, nachdem ein paar Projekte mit Versionsbezeichnern gefunden wurden, die sich nur durch ein nachgestelltes \n-Zeichen unterschieden und auf PyPI vorhanden waren.

Verschiedene andere Normalisierungsregeln wurden ebenfalls hinzugefügt, wie im separaten Abschnitt zur Versionsnormalisierung unten beschrieben.

Anhang A zeigt detaillierte Ergebnisse einer Analyse von PyPI-Distributionsversionsinformationen, wie sie am 8. August 2014 gesammelt wurden. Diese Analyse vergleicht das Verhalten des explizit geordneten Versionsschemas, das in diesem PEP definiert ist, mit dem De-facto-Standard, der durch das Verhalten von setuptools definiert ist. Diese Metriken sind nützlich, da die Absicht dieses PEP darin besteht, dem bestehenden Verhalten von setuptools so genau wie möglich zu folgen, während gleichzeitig Ausnahmen für nicht sortierbare Versionen gemacht werden (anstatt zu versuchen, eine geeignete Reihenfolge zu erraten, wie es setuptools tut).

Eine meinungsfreundlichere Beschreibung des Versionsschemas

Wie in PEP 386 liegt der Schwerpunkt darauf, bestehende Praktiken zu kodifizieren, um sie besser für die Automatisierung geeignet zu machen, anstatt von bestehenden Projekten zu verlangen, dass sie nicht-triviale Änderungen an ihrem Workflow vornehmen. Das Standardschema erlaubt jedoch erheblich mehr Flexibilität, als für die überwiegende Mehrheit einfacher Python-Pakete erforderlich ist (die oft nicht einmal Wartungsreleases benötigen – viele Benutzer sind zufrieden damit, auf ein neues Feature-Release aktualisieren zu müssen, um Fehlerbehebungen zu erhalten).

Zum Nutzen von unerfahrenen Entwicklern und von erfahrenen Entwicklern, die die verschiedenen Anwendungsfälle besser verstehen möchten, geht die Spezifikation nun viel detaillierter auf die Komponenten des definierten Versionsschemas ein, einschließlich Beispielen, wie jede Komponente in der Praxis verwendet werden kann.

Das PEP weist die Entwickler auch explizit in Richtung semantischer Versionierung (ohne diese zu verlangen) und rät von der Verwendung mehrerer Aspekte des vollständigen Versionierungsschemas ab, die weitgehend aufgenommen wurden, um esoterische Eckfälle in den Praktiken bestehender Projekte und bei der Neuverpackung von Software für Linux-Distributionen abzudecken.

Beschreibung von Versionsspezifikatoren neben dem Versionsschema

Der Hauptgrund für die überhaupt vorhandene standardisierte Versionsschema besteht darin, zuverlässige automatisierte Abhängigkeitsanalysen zu erleichtern. Es ist sinnvoller, den primären Anwendungsfall für Versionsbezeichner neben ihrer Definition zu beschreiben.

Änderung der Interpretation von Versionsspezifikatoren

Die frühere Interpretation von Versionsspezifizierern machte es sehr einfach, versehentlich eine Prä-Release-Version einer Abhängigkeit herunterzuladen. Dies erschwerte es wiederum den Entwicklern, Prä-Release-Versionen von Software im Python Package Index zu veröffentlichen, da selbst die Kennzeichnung des Pakets als "versteckt" nicht ausreichte, um automatisierte Tools vom Herunterladen abzuhalten, und es den Benutzern auch erschwerte, die Testversion manuell über die Haupt-PyPI-Weboberfläche zu erhalten.

Die frühere Interpretation schloss auch Post-Releases aus einigen Versionsspezifizierern ohne ausreichend begründeten Grund aus.

Die aktualisierte Interpretation soll es schwierig machen, versehentlich eine Prä-Release-Version als erfüllende Abhängigkeit zu akzeptieren, während Prä-Release-Versionen weiterhin automatisch abgerufen werden können, wenn dies die einzige Möglichkeit ist, eine Abhängigkeit zu erfüllen.

Die Versionsbeschränkung "einige Vorwärtskompatibilität angenommen" leitet sich vom Operator für "pessimistische Versionsbeschränkung" der Ruby-Community [2] ab, um Projekten zu ermöglichen, einen vorsichtigen Ansatz für Vorwärtskompatibilitätsversprechen zu verfolgen und gleichzeitig eine Mindestanforderung für ihre Abhängigkeiten einfach festzulegen. Die Schreibweise der Klausel für kompatible Releases (~=) ist von den Ruby- (~>) und PHP- (~) Äquivalenten inspiriert.

Weitere Verbesserungen sind für die Handhabung der parallelen Installation mehrerer Versionen derselben Bibliothek geplant, diese werden jedoch von Aktualisierungen der Installationsdatenbankdefinition sowie von verbesserten Tools für die dynamische Pfadmanipulation abhängen.

Die Syntax für nachgestellte Wildcards zur Anforderung von präfixbasierter Versionsabgleichung wurde hinzugefügt, um die sinnvolle Definition von Klauseln für kompatible Releases zu ermöglichen.

Unterstützung für datumsbasierte Versionskennungen

Der Ausschluss datumsbasierter Versionen verursachte erhebliche Probleme bei der Migration von pytz zu den neuen Metadatenstandards. Er löste auch Bedenken bei den OpenStack-Entwicklern aus, da diese ein datumsbasiertes Versionierungsschema verwenden und zu den neuen Metadatenstandards migrieren möchten, ohne es zu ändern.

Hinzufügen von Versionsepochen

Versions-Epochen werden aus demselben Grund hinzugefügt, aus dem sie Teil anderer Versionierungsschemata sind, wie z. B. die der Fedora- und Debian-Linux-Distributionen: um Projekten zu ermöglichen, ihren Ansatz für die Nummerierung von Releases gracefully zu ändern, ohne dass ein neues Release eine niedrigere Versionsnummer als frühere Releases zu haben scheint und ohne den Namen des Projekts ändern zu müssen.

Insbesondere die Unterstützung von Versions-Epochen ermöglicht es einem Projekt, das zuvor datumsbasierte Versionierung verwendete, zur semantischen Versionierung zu wechseln, indem eine neue Versions-Epoche angegeben wird.

Das Zeichen ! wurde gewählt, um eine Epochenversion zu trennen, anstatt das Zeichen :, das in anderen Systemen üblicherweise verwendet wird, da : kein gültiges Zeichen in einem Windows-Verzeichnisnamen ist.

Hinzufügen von direkten Referenzen

Direkte Verweise werden als "Escape-Klausel" hinzugefügt, um unübersichtliche reale Situationen zu bewältigen, die sich nicht sauber in das Standardverteilungsmodell einfügen lassen. Dies schließt Abhängigkeiten von unveröffentlichten Software für den internen Gebrauch ein, sowie die Handhabung komplexerer Kompatibilitätsprobleme, die beim Umwickeln von Drittanbieter-Bibliotheken als C-Erweiterungen auftreten können (dies ist von besonderem Interesse für die wissenschaftliche Gemeinschaft).

Indexservern wird bewusst viel Freiheit eingeräumt, direkte Verweise abzulehnen, da sie in erster Linie als Werkzeug für Integratoren und nicht für Publisher gedacht sind. PyPI durchläuft derzeit insbesondere den Prozess der *Beseitigung* von Abhängigkeiten von externen Verweisen, da unzuverlässige externe Dienste die Installationsvorgänge verlangsamen und die scheinbare Zuverlässigkeit von PyPI selbst verringern.

Hinzufügen von beliebiger Gleichheit

Beliebige Gleichheit wird als "Escape-Klausel" hinzugefügt, um den Fall zu behandeln, in dem jemand ein Projekt installieren muss, das eine nicht-konforme Version verwendet. Obwohl dieses PEP eine Kompatibilität von ~97% mit den bereits auf PyPI vorhandenen Versionen erreicht, gibt es immer noch ~3% der Versionen, die nicht analysiert werden können. Dieser Operator bietet eine einfache und effektive Möglichkeit, sie dennoch zu referenzieren, ohne die Semantik dessen "raten" zu müssen, was sie bedeuten (was erforderlich wäre, wenn etwas anderes als strenge zeichenkettenbasierte Gleichheit unterstützt würde).

Hinzufügen von lokalen Versionskennungen

Es ist eine Tatsache, dass Downstream-Integratoren oft Fehlerkorrekturen von Upstream in ältere Versionen zurückportieren müssen. Es ist einer der Dienste, für die Linux-Distributor bezahlt werden, und Anwendungsentwickler können auch Patches anwenden, die sie für gebündelte Abhängigkeiten benötigen.

Historisch gesehen war diese Praxis für plattformübergreifende sprachspezifische Verteilungswerkzeuge unsichtbar – die gemeldete "Version" in den Upstream-Metadaten ist dieselbe wie für den unveränderten Code. Diese Ungenauigkeit kann dann Probleme verursachen, wenn versucht wird, mit einer Mischung aus vom Integrator bereitgestelltem Code und unverändertem Upstream-Code zu arbeiten oder sogar nur zu identifizieren, welche Version der Software installiert ist.

Die Einführung von lokalen Versionsbezeichnern und "lokalen Versions-Labels" in das Versionierungsschema mit der entsprechenden Metadaten-Erweiterung python.integrator ermöglicht die genaue Darstellung dieser Art von Aktivität, was die Interoperabilität zwischen den Upstream-Tools und verschiedenen integrierten Plattformen verbessern sollte.

Das genau gewählte Schema ist weitgehend am bestehenden Verhalten von pkg_resources.parse_version und pkg_resources.parse_requirements orientiert, wobei der Hauptunterschied darin besteht, dass, während pkg_resources bei der Vergleich von Versionen für exakte Übereinstimmungen derzeit immer das Suffix berücksichtigt, das PEP erfordert, dass das lokale Versions-Label der Kandidatenversion ignoriert wird, wenn kein lokales Versions-Label in der Versionsspezifizierer-Klausel vorhanden ist. Darüber hinaus versucht das PEP nicht, eine Struktur auf die lokalen Versions-Labels zu erzwingen (abgesehen von der Beschränkung des Satzes zulässiger Zeichen und der Definition ihrer Reihenfolge).

Diese Änderung soll sicherstellen, dass eine vom Integrator bereitgestellte Version wie pip 1.5+1 oder pip 1.5+1.git.abc123de immer noch einen Versionsspezifizierer wie pip>=1.5 erfüllt.

Das Pluszeichen wird hauptsächlich zur Lesbarkeit lokaler Versionsbezeichner gewählt. Es wurde anstelle des Bindestrichs gewählt, um zu verhindern, dass pkg_resources.parse_version es als Vorabversion interpretiert, was wichtig ist, um eine erfolgreiche Migration zum neuen, strukturierteren Versionierungsschema zu ermöglichen. Das Pluszeichen wurde anstelle einer Tilde gewählt, da die Tilde in Debians Versionssortieralgorithmus eine besondere Bedeutung hat.

Bereitstellung expliziter Versionsnormalisierungsregeln

Historisch gesehen war der De-facto-Standard für die Analyse von Versionen in Python der Befehl pkg_resources.parse_version aus dem setuptools-Projekt. Dieser versucht nicht, *irgendeine* Version abzulehnen, sondern versucht, aus dem, was er erhält, etwas Sinnvolles zu machen, mit unterschiedlichem Erfolg. Er hat ein paar einfache Regeln, aber ansonsten stützt er sich mehr oder weniger stark auf den String-Vergleich.

Die in diesem PEP bereitgestellten Normalisierungsregeln dienen hauptsächlich dazu, entweder die Kompatibilität mit pkg_resources.parse_version zu erhöhen, insbesondere in dokumentierten Anwendungsfällen wie rev, r, pre usw., oder etwas Sinnvolleres mit bereits auf PyPI vorhandenen Versionen zu tun.

Alle möglichen Normalisierungsregeln wurden danach abgewogen, ob sie *wahrscheinlich* Mehrdeutigkeiten verursachen würden (z. B. während jemand ein Schema entwickeln könnte, bei dem v1.0 und 1.0 als unterschiedliche Releases gelten, ist die Wahrscheinlichkeit, dass jemand dies tatsächlich tut, geschweige denn in einem bemerkenswerten Umfang, ziemlich gering). Sie wurden auch danach abgewogen, wie pkg_resources.parse_version einen bestimmten Versionsstring behandelte, insbesondere in Bezug auf die Sortierung. Schließlich wurde jede Regel gegen die Arten von zusätzlichen Versionen abgewogen, die sie zuließ, wie "hässlich" diese Versionen aussahen, wie schwer sie zu parsen waren (sowohl mental als auch mechanisch) und wie viel zusätzliche Kompatibilität sie bringen würde.

Die Breite der möglichen Normalisierungen wurde auf Dinge beschränkt, die leicht als Teil des Parsens der Version implementiert werden können und nicht als Vor-Parsing-Transformationen, die auf die Versionen angewendet werden. Dies geschah, um die Nebenwirkungen jeder Transformation zu begrenzen, da einfache Suchen-und-Ersetzen-artige Transformationen die Wahrscheinlichkeit von mehrdeutigen oder "Schrott"-Versionen erhöhen.

Für eine ausführliche Diskussion der verschiedenen Arten von Normalisierungen, die in Betracht gezogen wurden, siehe den Proof of Concept für PEP 440 innerhalb von pip [5].

Zulassen von Unterstrichen in der Normalisierung

Es gibt nicht viele Projekte auf PyPI, die einen Unterstrich (_) in der Versionszeichenkette verwenden. Dieses PEP erlaubt jedoch seine Verwendung überall dort, wo ein Bindestrich (-) akzeptabel ist. Der Grund dafür ist, dass das Wheel-Normalisierungsschema vorsieht, dass der Bindestrich (-) zu einem Unterstrich (_) normalisiert wird, um das Parsen des Dateinamens zu erleichtern.