Qiskit SDK versionsstrategie
Die Versionsnummern von Qiskit folgen der Semantischen Versionierung.
Die Versionsnummer setzt sich aus drei Hauptkomponenten zusammen: Haupt-, Neben- und patch-Version. Zum Beispiel ist in der Versionsnummer X.Y.Z X die Hauptversion, Y ist die Nebenversion und Z ist die Patch-Version.
Änderungen an der API, die Kompatibilitätsprobleme verursachen, sind den Veröffentlichungen neuer Hauptversionen vorbehalten. Der Mindestzeitraum zwischen der Veröffentlichung einer Hauptversion beträgt ein Jahr. In Nebenversionen werden neue Funktionen und Fehlerbehebungen eingeführt, ohne die API-Kompatibilität zu beeinträchtigen, und sie werden regelmäßig (derzeit etwa alle drei Monate) ausschließlich für die aktuelle Hauptversion veröffentlicht. Patch-Versionen enthalten Korrekturen für Fehler, die in der aktuellsten Nebenversion jeder aktiv unterstützten Release-Serie (d. h. der Hauptversion) festgestellt wurden. Wir unterstützen jeweils höchstens zwei Release-Serien gleichzeitig, was nur während der Übergangsphase nach der Veröffentlichung einer neuen Hauptversion der Fall ist, wie im Folgenden näher beschrieben.
Veröffentlichungsplan
Beispiel für einen X-Rhythmus bei Hauptversionen:
Einen aktuellen Versionsplan finden Sie in der Meilensteinliste des Projekts Qiskit GitHub, die immer den aktuellen Versionsplan enthält.
Bei der Veröffentlichung einer neuen Hauptversion wird die vorherige Hauptversion mindestens sechs Monate lang nur für Fehlerbehebungen und ein Jahr lang für Sicherheitsbehebungen unterstützt. Während während dieser Zeit werden nur Patches für diese Hauptversion veröffentlicht. Eine letzte Patch-Version wird veröffentlicht, wenn der Support eingestellt wird, und diese Veröffentlichung dokumentiert auch das Ende der Unterstützung für diese Hauptversionsreihe. Ein längeres support-Fenster ist für die vorherige Hauptversion erforderlich, da dies den nachgelagerten Qiskit-Kunden und ihren Benutzern die Möglichkeit gibt, ihren Code zu migrieren. Nachgelagerte Bibliotheken, die von Qiskit abhängen, sollten ihre minimal erforderliche Qiskit-Version nicht sofort nach der Veröffentlichung auf eine neue hauptversion anheben, da die Benutzerbasis der Bibliothek Zeit braucht um sich auf die neuen API-Änderungen einzustellen. Ein erweitertes Support-Fenster für die vorherige Hauptversion von Qiskit gibt nachgelagerten Projekten Zeit, die kompatibilität mit der nächsten Hauptversion zu gewährleisten. Nachgelagerte Projekte können unterstützung für jeweils zwei Versionsreihen anbieten, um ihren Benutzern einen Migrationspfad zu bieten.
Für die Zwecke der semantischen Versionierung gilt die öffentliche API von Qiskit als jedes dokumentierte Modul, jede Klasse, Funktion oder Methode, die nicht als privat gekennzeichnet ist (mit einem Unterstrich _ Präfix). Es können jedoch explizite Ausnahmen gemacht werden für bestimmte dokumentierte APIs. In solchen Fällen werden diese APIs eindeutig dokumentiert dass diese APIs noch nicht als stabile Schnittstellen gelten, und es wird eine für den Benutzer sichtbare Warnung bei jeder Verwendung dieser instabilen Schnittstellen ausgegeben. Außerdem wird in einigen situationen wird eine als privat gekennzeichnete Schnittstelle als Teil der öffentlichen API. Normalerweise kommt dies nur in zwei Fällen vor: entweder bei einer abstrakten Schnittstellendefinition definition, bei der die Unterklassen eine private Methode überschreiben/implementieren sollen als Teil der Definition einer Implementierung der Schnittstelle überschreiben/implementieren sollen, oder fortgeschrittene low-Level-Methoden, die stabile Schnittstellen haben, aber nicht als sicher in der Anwendung gelten, da es Aufgabe des Benutzers ist, die Klasse/Sicherheitsinvarianten selbst aufrechtzuerhalten (das kanonische Beispiel hierfür ist die Methode QuantumCircuit._append ).
Die unterstützten Versionen von Python, die minimal unterstützte Rust-Version (zum Erstellen von Qiskit aus dem Quellcode), und alle Python Paketabhängigkeiten (einschließlich der minimalen unterstützten Versionen von Abhängigkeiten), die von Qiskit verwendet werden, sind nicht Teil der Abwärtskompatibilitäts kompatibilitätsgarantien und können sich während jeder Veröffentlichung ändern. Nur kleinere oder größere versionen werden die Mindestanforderungen für die Verwendung oder Erstellung von Qiskit (einschließlich der Hinzufügung neuer Abhängigkeiten), aber Patch-Korrekturen können auch Unterstützung für neue Versionen von Python oder andere Abhängigkeiten. Normalerweise wird die Mindestversion einer abhängigkeit nur erhöht, wenn ältere Versionen der Abhängigkeit nicht mehr unterstützt werden oder wenn es nicht möglich ist, die Kompatibilität zwischen der neuesten Version der abhängigkeit und der älteren Version aufrechtzuerhalten.
Upgrade-Strategie
Wenn eine neue Hauptversion veröffentlicht wird, ist der empfohlene Upgrade-Pfad wird empfohlen, zunächst ein Upgrade auf die neueste Unterversion der vorherigen Hauptversion version. Kurz vor einer neuen Hauptversion wird eine letzte Nebenversion veröffentlicht. Diese endgültige Nebenversion X.Y+1.0.0 ist gleichwertig mit X.Y.0 aber mit Warnungen und Verwerfungen für alle API-Änderungen, die die in der neuen Hauptversionsreihe vorgenommen werden.
So wird beispielsweise unmittelbar nach der Veröffentlichung von „ 1.0.0 “ eine Veröffentlichung von „ 0.46.0 “ veröffentlicht. Die Version „ 0.46.0 “ entspricht der Version „ 0.45.0 “, enthält jedoch zusätzliche Veraltungswarnungen, die die API-Änderungen dokumentieren, die im Rahmen der Version „ 1.0.0 “ vorgenommen wurden. Dieses Muster gilt für alle Hauptversions-Releases.
Qiskit-Benutzer sollten zunächst ein Upgrade auf diese letzte Nebenversion version aktualisieren, um eventuelle Verwerfungswarnungen zu sehen und ihre Qiskit nutzung anpassen, bevor sie eine möglicherweise brechende Version ausprobieren. Die vorherige hauptversion wird noch mindestens sechs Monate lang unterstützt, damit genügend Zeit für ein zu aktualisieren. Ein typisches Muster zur Bewältigung dieses Problems ist die Festlegung der maximalen Version, um die Verwendung der nächsten Hauptversionsreihe zu vermeiden, bis man sich der Kompatibilität sicher ist.
Wenn Sie zum Beispiel qiskit<2 in einer Anforderungsdatei angeben, während die aktuelle hauptversion von Qiskit 1 ist, stellt sicher, dass Sie eine Version von Qiskit verwenden, die keine bahnbrechenden API-Änderungen enthält.
Die Begrenzung der Version auf weniger als die nächste Hauptversion stellt sicher, dass Sie alle Verwerfungswarnungen sehen, bevor eine veröffentlichung einer Hauptversion.
Ohne die Kappe installiert pip standardmäßig die neueste verfügbare Version.
Das QPY-Serialisierungsformat ist rückwärtskompatibel, so dass eine neue Qiskit-Version immer eine QPY datei laden kann, die mit einer früheren Version von Qiskit erzeugt wurde. Das Format ist jedoch nicht vorwärtskompatibel, so dass es im Prinzip nicht möglich ist qPY-Dateien, die mit einer neueren Version von Qiskit erzeugt wurden, mit einer älteren Version zu laden. Zur Erleichterung der Migration der Benutzer zwischen den Hauptversionen unterstützt die qiskit.qpy.dump() funktion immer mindestens eine Überlappungsversion zwischen der Version X.0.0 und der Version X-1.Y.0 (wobei Y die letzte Nebenversion der dieser Serie ist). Der Parameter qiskit.qpy.dump(..., version=...) ermöglicht das Speichern von Dateien im QPY-Format, die von beiden Hauptversionen der neueren Version geladen werden können version geladen werden können. Weitere Einzelheiten finden Sie in RFC 0020.
Vorabveröffentlichungen
Für jede Neben- und Hauptversion veröffentlicht Qiskit Vorabversionen, die kompatibel sind mit PEP440. In der Regel sind dies Freigabekandidaten der Form X.Y.0rc1. Die rc Versionen haben eine fertige API-Oberfläche und werden zum Testen einer zukünftigen Version verwendet.
Bitte beachten Sie: Wenn eines der „ PEP440 “-Pre-Release-Suffixe (wie z. B. a, b, oder pre)
veröffentlicht wird, gelten dafür nicht dieselben Garantien wie für eine -Version rc ; es handelt sich
lediglich um eine Vorschauversion. Die API kann sich zwischen diesen Vorabversionen
und der endgültigen Version mit dieser Versionsnummer ändern. Beispielsweise X.0.0pre1 könnte eine
andere API haben als die endgültige Version X.0.0.
Nachveröffentlichungen
Wenn es Probleme mit der Verpackung einer Veröffentlichung gibt, wird möglicherweise eine Nachveröffentlichung herausgegeben werden, um dies zu korrigieren. Diese haben die Form X.Y.Z.1 , wobei die vierte ganzzahl angibt, dass es sich um die erste Nachveröffentlichung der Version X.Y.Z handelt.
Zum Beispiel hatte die qiskit-terra (der alte Paketname für Qiskit) 0.25.2 hatte ein Problem mit der Veröffentlichung des sdist-Pakets, und eine Nachveröffentlichung 0.25.2.1 wurde veröffentlicht, die dieses Problem behebt. Der Code war identisch, und 0.25.2.1 nur das Verpackungsproblem für die Freigabe behoben.
Wie Mitwirkende Veraltungen kennzeichnen können
Anweisungen zum Hinzufügen von Deprecations zum Quellcode finden Sie im Deprecation Guide im Qiskit SDK Repository.