Entwicklerwerkzeuge
Eine Version je Zeile: Schreibweise normalisieren, Reihenfolge prüfen oder Bedingungen mit Komma verknüpfen.
Eingabe hinzufügen oder ein Beispiel laden.
Die Eingabe wird in diesem Browser verarbeitet und nicht an einen Server gesendet.
Kommas bedeuten UND. Leere Bedingungen setzen keine Grenzen. Unterstützt: ~= == != <= >= < > ===; .* nur bei Release-Präfixen mit == oder !=.
Höchstens 1.000 nichtleere Zeilen; 256 UTF-16-Einheiten je Zeile, 2.048 je Bedingung, 100.000 insgesamt. Die Eingabe bleibt erhalten.
Aktuelle Kandidaten werden geprüft…
Die PEP 440 Versionsprüfung hilft, wenn eine neuere Veröffentlichung trotzdem nicht in den gewünschten Versionsbereich fällt. Gültige Schreibweise, Rangfolge und Eignung als Kandidat sind unterschiedliche Ergebnisse, die hier getrennt sichtbar bleiben.
Wer Versionen vergleichen möchte, sollte 1.0 und 1.0.0 nicht als verschiedene Rangstufen behandeln. Epoch, Entwicklungsstände und lokale Kennungen folgen eigenen Regeln; alphabetisches Sortieren oder ein npm-Rechner reicht dafür nicht aus.
Die PEP 440 Versionsprüfung zeigt zu v01.1 die Normalform 1.1, ohne die Eingabe zu überschreiben. Aufgeklappte Zeilen zeigen Epoch, Release, pre, post, dev und local. So lässt sich erkennen, ob lediglich die Schreibweise oder tatsächlich eine Komponente anders ist.
Die automatische Auswahl betrachtet zunächst alle Kandidaten, die sämtliche Bedingungen erfüllen. Gibt es eine passende Nicht-Vorabversion, erhält sie Vorrang. Andernfalls können passende Vorabversionen zum Zug kommen. Eine zusätzliche stabile Version kann deshalb andere Zeilen beeinflussen.
Normalisieren prüft Schreibweisen ohne Bereichsfilter. Sortieren verwendet die Python-Rangfolge und erhält bei Gleichstand die Eingabereihenfolge. Der Abgleich lässt die Liste unverändert und trennt eine verletzte Bedingung von einem Ausschluss durch die Vorabversionsregel.
Entfernen Sie einen passenden stabilen Kandidaten und beobachten Sie den Rückgriff auf Vorabversionen. Einschließen ändert keine numerische Grenze: 1.0rc1 liegt weiterhin vor 1.0 und erfüllt >=1.0 nicht.
Die Automatik wartet 350 ms. Ausgeschaltet stehen Prüfen und Strg/Cmd+Enter zur Verfügung. Änderungen sperren alte Exporte sofort. Beispiel und Leeren zeigen zunächst eine Vorschau; nach dem Anwenden stellt Rückgängig Eingabe und Bericht wieder her.
v-Präfixe, führende Nullen, Bezeichnungen wie alpha oder preview sowie lokale Trennzeichen werden vereinheitlicht. Die Anzahl der Release-Komponenten bleibt erhalten: 1.0.0 wird angezeigt wie eingegeben, obwohl es beim Vergleich denselben Rang wie 1.0 hat.
Zuerst zählt die Epoch, danach folgen Release-Zahlen und die Regeln für dev, alpha, beta, rc, finale und post-Veröffentlichungen. Lokale Zahlen werden numerisch verglichen. Auch Komponenten oberhalb der sicheren JavaScript-Ganzzahlgrenze werden nicht gerundet.
Unterstützt werden ~=, ==, !=, <=, >=, <, > und ===. Das Komma bedeutet UND. Bei == und != sind Release-Präfixe wie 1.4.* möglich. Der Bericht nennt weiterhin die ursprüngliche physische Zeile, selbst wenn Leerzeilen übersprungen wurden.
Eine ungültige Version betrifft ihre Zeile; eine ungültige Bedingung verhindert die gesamte Berechnung. Beim Sortieren stehen ungültige Einträge hinten. Die Ansicht wächst in Schritten von 50, der JSON-Bericht enthält immer sämtliche verarbeiteten Zeilen samt Fehlercodes.
Der Operator kombiniert eine Untergrenze mit einem Release-Präfix. ~=1.4 erlaubt ab 1.4 die Reihe 1.*, während ~=1.4.0 in 1.4.* bleibt. ~=1 ist mit nur einer Komponente ungültig. Die Entscheidung über Vorabversionen erfolgt zusätzlich.
Die automatische Filterung kann Vorabversionen verwenden, wenn keine passende Nicht-Vorabversion vorhanden ist. Ein hinzugefügter finaler oder post-Kandidat kann diese Entscheidung ändern. Einschließen zeigt alle numerisch passenden Kandidaten, Ausschließen verhindert auch den automatischen Rückgriff.
Bei identischer öffentlicher Version folgt die lokale Variante dahinter: 1.0 < 1.0+abc. Numerische lokale Komponenten folgen auf Textkomponenten. Gleiche normalisierte Werte behalten ihre Eingabereihenfolge. Anders als SemVer-Buildmetadaten beeinflusst local also den Rang.
Bei == und != ist das erlaubt, etwa ==1.0+linux.1. Bei >= oder ~= ist es ungültig. Ein öffentliches ==1.0 kann dagegen 1.0+linux.1 akzeptieren, weil es keinen bestimmten lokalen Build verlangt.
packaging.version.Version bietet die PEP-konforme Rangfolge. Die Browserimplementierung wird gegen packaging 26.0 geprüft. Ein Zeichenkettenvergleich ordnet beispielsweise 1.10 und 1.9 falsch; eine andere Versionsnorm deckt Epoch und post nicht unbedingt ab.
Nein. ==1.0.* ist ein gültiger Release-Präfix, ==1.0rc1.* und ==1.0.post1.* sind ungültig. Für solche Zusätze sind genaue Gleichheit oder normale Grenzen nötig. Ein Präfix hebt die Vorabversionsregel nicht auf.
Unerwartetes Versionsergebnis?
Nutzen Sie die PEP 440 Versionsprüfung mit der vollständigen Liste aus Ihrer Untersuchung. Prüfen Sie Fehlerzeilen und die Auswahlregel, bevor Sie den aktuellen Bericht mit Originalwerten und Bedingungen speichern.