Rückwärtskompatibilitätspolitik

Pytest ist ein sich aktiv entwickelndes Projekt, das seit Jahrzehnten besteht. Wir lernen ständig neue und bessere Strukturen kennen, um verschiedene Details über das Testen auszudrücken.

Bei der Implementierung dieser Änderungen versuchen wir, einen einfachen Übergang zu gewährleisten und wollen unseren Benutzern und Community-/Plugin-Autoren keine unnötigen Umstellungen aufzwingen.

Derzeit betrachtet pytest mehrere Arten von Rückwärtskompatibilitätsübergängen

1. trivial: APIs, die sich trivial in den neuen Mechanismus übersetzen lassen und keine problematischen Änderungen verursachen.

   Wir versuchen, diese auf unbestimmte Zeit zu unterstützen und ermutigen Benutzer, durch Dokumentation zu neueren oder besseren Mechanismen zu wechseln.

2. übergangsweise: die alten und neuen APIs stehen nicht im Konflikt, und wir können Benutzern den Übergang erleichtern, indem wir Warnungen verwenden, während beide für einen längeren Zeitraum unterstützt werden.

   Wir werden die Entfernung von veralteter Funktionalität erst in Hauptversionen beginnen (z. B. wenn wir etwas in 3.0 veraltet erklären, werden wir es in 4.0 entfernen) und es mindestens zwei Nebenversionen lang beibehalten (z. B. wenn wir etwas in 3.9 veraltet erklären und 4.0 die nächste Version ist, beginnen wir mit der Entfernung in 5.0, nicht in 4.0).

   Eine als veraltet markierte Funktion, deren Entfernung für die Hauptversion X geplant ist, verwendet die Warnungsklasse PytestRemovedInXWarning (eine Unterklasse von PytestDeprecationWarning).

   Wenn die Veraltung abläuft (z. B. wird 4.0 veröffentlicht), werden wir die veraltete Funktionalität nicht sofort entfernen, sondern die Standard-Warnfilter verwenden, um PytestRemovedInXWarning (z. B. PytestRemovedIn4Warning) standardmäßig in Fehler umzuwandeln. Dieser Ansatz macht deutlich, dass die Entfernung unmittelbar bevorsteht, und gibt Ihnen immer noch Zeit, die veraltete Funktion von einer Warnung in einen Fehler umzuwandeln, damit sie zu gegebener Zeit behandelt werden kann. In der nächsten Nebenversion (z. B. 4.1) wird die Funktion effektiv entfernt.

3. Echte Brüche sollten nur in Betracht gezogen werden, wenn ein normaler Übergang unangemessen unhaltbar ist und wichtige Entwicklungen oder Funktionen um Jahre verzögern würde. Darüber hinaus sollten sie auf APIs beschränkt sein, bei denen die Anzahl der tatsächlichen Benutzer sehr gering ist (z. B. nur einige Plugins betroffen) und die im Voraus mit der Community koordiniert werden können.

   Beispiele für solche bevorstehenden Änderungen

   • Entfernung von pytest_runtest_protocol/nextitem - #895

   • Umordnung des Knotenbaums zur Aufnahme von FunctionDefinition

   • Umordnung von SetupState #895

   Echte Brüche müssen zuerst in einem Issue angekündigt werden, das Folgendes enthält:

   • Detaillierte Beschreibung der Änderung

   • Begründung

   • Erwartete Auswirkungen auf Benutzer und Plugin-Autoren (Beispiel in #895)

   Nachdem kein starkes -1 bei dem Issue vorliegt, sollte es mit einem ersten Proof-of-Concept Pull Request fortgesetzt werden.

   Dieser POC dient sowohl als Koordinationspunkt zur Einschätzung der Auswirkungen als auch als Inspiration, um letztendlich eine Übergangslösung zu finden.

   Nach angemessener Zeit kann der PR zusammengeführt werden, um eine neue Hauptversion zu bilden.

   Damit der PR von POC zu Akzeptanz reift, muss er Folgendes enthalten: * Einrichtung von Deprecations-Fehlern/-Warnungen, die Benutzern helfen, ihren Code zu korrigieren und zu portieren. Wenn es möglich ist, eine Deprecations-Periode unter der aktuellen Serie einzuführen, bevor es zu einem tatsächlichen Bruch kommt, sollte dies in einem separaten PR eingeführt und Teil des aktuellen Release-Streams sein. * Detaillierte Beschreibung der Begründung und Beispiele für die Portierung von Code in doc/en/deprecations.rst.

Historie

Fokus primär auf reibungslosen Übergang - Haltung (vor 6.0)

Die Aufrechterhaltung der Rückwärtskompatibilität hat im pytest-Projekt eine sehr hohe Priorität. Obwohl wir im Laufe der Jahre Funktionalität veraltet haben, wird der Großteil davon immer noch unterstützt. Alle Veraltungen in pytest wurden vorgenommen, weil einfachere oder effizientere Wege zur Erreichung derselben Aufgaben entstanden sind, wodurch die alte Vorgehensweise unnötig wurde.

Mit der Veröffentlichung von pytest 3.0 haben wir ein klares Kommunikationsschema eingeführt, wann wir die alten, kaputten Teile tatsächlich entfernen und Sie höflich bitten, die neuen und besseren zu verwenden, während wir Ihnen genügend Zeit geben, Ihre Tests anzupassen oder Bedenken zu äußern, falls es berechtigte Gründe gibt, veraltete Funktionalität beizubehalten.

Zur Kommunikation von Änderungen geben wir Deprecations-Warnungen über eine benutzerdefinierte Warnhierarchie aus (siehe Interne pytest-Warnungen). Diese Warnungen können mit den Standardmitteln unterdrückt werden: -W Kommandozeilenflag oder filterwarnings ini-Optionen (siehe Wie man Warnungen abfängt), aber wir empfehlen, diese sparsam und nur vorübergehend zu verwenden und die Warnungen nach Möglichkeit zu beachten.

Wir werden die Entfernung von veralteter Funktionalität erst in Hauptversionen beginnen (z. B. wenn wir etwas in 3.0 veraltet erklären, werden wir es in 4.0 entfernen) und es mindestens zwei Nebenversionen lang beibehalten (z. B. wenn wir etwas in 3.9 veraltet erklären und 4.0 die nächste Version ist, beginnen wir mit der Entfernung in 5.0, nicht in 4.0).

Wenn die Veraltung abläuft (z. B. 4.0 wird veröffentlicht), werden wir die veraltete Funktionalität nicht sofort entfernen, sondern die Standard-Warnfilter verwenden, um sie standardmäßig in Fehler umzuwandeln. Dieser Ansatz macht deutlich, dass die Entfernung unmittelbar bevorsteht, und gibt Ihnen immer noch Zeit, die veraltete Funktion von einer Warnung in einen Fehler umzuwandeln, damit sie zu gegebener Zeit behandelt werden kann. In der nächsten Nebenversion (z. B. 4.1) wird die Funktion effektiv entfernt.

Roadmap für Veraltung

Funktionen, die derzeit veraltet und in früheren Versionen entfernt wurden, finden Sie unter Veraltungen und Entfernungen.

Wir verfolgen zukünftige Veraltungen und Entfernungen von Funktionen mithilfe von Meilensteinen und den Labels deprecation und removal auf GitHub.

Python-Versionsunterstützung

Veröffentlichte pytest-Versionen unterstützen alle Python-Versionen, die zum Zeitpunkt der Veröffentlichung aktiv gewartet werden

pytest-Version	Min. Python-Version
8.4+	3.9+
8.0+	3.8+
7.1+	3.7+
6.2 - 7.0	3.6+
5.0 - 6.1	3.5+
3.3 - 4.6	2.7, 3.4+

Status der Python-Versionen.