SQLAlchemy herunterladen

Punkt-Releases

Punkt-Releases sind die häufigste Release-Serie und treten bei aktiven Projekten oft alle paar Wochen oder seltener auf. Ein Punkt-Release sollte immer vollständig kompatibel sein, sodass jedes Projekt ohne Änderungen auf diese Version umsteigen kann, gegeben eine bestimmte Haupt-/Neben-Serie.. Das bedeutet, wenn ein Projekt auf Version 1.2.3 von SQLAlchemy ist, sollte dieses Projekt im Idealfall direkt auf die neueste 1.2.x-Serie, wie z.B. 1.2.19, aktualisiert werden können, ohne auf Zwischen-Releases umsteigen zu müssen.

Ein Punkt-Release enthält drei Kategorien von Änderungen

• Fehlerbehebungen - Der Hauptzweck eines Punkt-Releases ist die Veröffentlichung von Fehlerbehebungen ohne rückwärts inkompatible Änderungen. Eine Fehlerbehebung, die als zu riskant für die Rückwärtskompatibilität eingestuft wird, wird stattdessen in ein Neben-Release aufgenommen.
• Anwendungsfall-Ergänzungen - Ein "Anwendungsfall" ist eine Änderungskategorie, die zwischen einer "Fehlerbehebung" und einem "Feature" liegt, und sie beziehen sich meist auf die Unterstützung neuer Datenbankfunktionen. Da neue Datenbankfunktionen kontinuierlich erstellt oder von Benutzern angefordert werden und sich normalerweise auf bestimmte Datentypen oder kleine SQL-Syntaxen beziehen, werden diese Funktionen oft in einem Punkt-Release aufgenommen, sofern sie die Rückwärtskompatibilität innerhalb von SQLAlchemy oder innerhalb von Alembic-Migrationen nicht beeinträchtigen. Größere Anwendungsfall-Ergänzungen werden in einem Neben-Release veröffentlicht.
• Kleine Feature-Ergänzungen - Da der Release-Zyklus für Punkt-Releases alle paar Wochen dauert, während der Release-Zyklus für ein Neben-Release normalerweise mindestens ein Jahr oder länger ist, werden Feature-Ergänzungen, die keine Auswirkungen auf aktuellen Code oder APIs haben, oft in Punkt-Releases aufgenommen; ein Beispiel hierfür ist die Möglichkeit, Unteroptionen bei einem ORM-Loader zu erstellen.

Beachten Sie, dass Punkt-Releases zwar der konservativste und häufigste Release-Stream sind, es aber immer möglich ist, dass versehentliche Regressionen auftreten. Es wird empfohlen, dass Projekte ihre Software immer vollständig testen, einschließlich der Verwendung von Test-Suiten und/oder Staging-Umgebungen, wenn sie auf eine neue Version einer Software der SQLAlchemy-Organisation aktualisieren.

Signifikante Neben-Releases

Neben-Releases in SQLAlchemy sind eigentlich "große" Ereignisse, da sie in der Regel ein Jahr zur Erstellung benötigen; für verwandte Projekte können Neben-Releases seltener vorkommen. Wir bezeichnen sie möglicherweise als Signifikante Neben-Releases, um anzuzeigen, dass es sich um große Ereignisse handelt, während wir gleichzeitig die Verwechslung mit dem Namen "Haupt" vermeiden, der sich normalerweise auf die linkeste Ziffer im Versionsschema bezieht. Eine Änderung im Neben-Release bedeutet, dass das Projekt Änderungen enthält, die typischerweise rückwärtskompatibel sind innerhalb des Bereichs von nicht zuvor abgekündigten APIs und aktuellen Python-Versionen, mit einem gewissen Risiko für Nicht-Rückwärtskompatibilität, insbesondere innerhalb von SQLAlchemy selbst; dieses Risiko ist aufgrund der Art der Änderungen normalerweise unvermeidlich.

Aus diesem Grund ist ein "Signifikantes Neben-Release" für SQLAlchemy selbst nicht wirklich "klein", und es gibt immer einen umfangreichen Abschnitt mit Migrationshinweisen, der jede API-Anpassung und Verhaltensänderung im Detail beschreibt, die möglicherweise identifiziert werden muss. Für andere Projekte bezieht sich ein Neben-Release typischerweise auf Änderungen in der Unterstützung von Python-Versionen, wie z.B. das Abbrechen der Unterstützung für Python 2.6, oder Alembic, das die Unterstützung für SQLAlchemy 0.9 abkürzt; eine allgemeine Vorstellung davon, was neu ist, finden Sie in der Changelog.

Ein Signifikantes Neben-Release, insbesondere in SQLAlchemy selbst, wird Folgendes enthalten

• Haupt-Features - Neue API-Features und -Funktionen sowie strukturelle und Leistungsverbesserungen sind Teil jedes Neben-Releases für SQLAlchemy selbst und sehr oft auch für verwandte Projekte. Diese Ergänzungen sind im Allgemeinen vollständig rückwärtskompatibel, jedoch ändern sie oft viel Code intern, was ein höheres Risiko für Regressionen birgt, insbesondere in SQLAlchemy; diese Regressionen werden normalerweise innerhalb der ersten Punkt-Releases eines neuen Neben-Releases behoben. Wie immer sollten nachgelagerte Anwendungen ihre Test-Suiten ausführen und alle Probleme mit einem neuen Neben-Release melden.

• Verhaltensänderungen - Die meisten Verhaltensänderungen sind subtil und verursachen im Allgemeinen wahrscheinlich keine Probleme. Diese Änderungen können jedoch rückwärts inkompatibel mit Endbenutzer-Code sein, der sich entweder auf ein zuvor fehlerhaftes Verhalten stützt oder der das alte Verhalten umging, das nicht mehr das gleiche Ergebnis liefern wird. Ein typisches Beispiel ist eine SQL-Renderung, die zuvor nicht richtig zitiert oder maskiert wurde und dann repariert wird; nachgelagerte Anwendungen werden dieses Problem typischerweise umgehen, indem sie die Zitierung manuell anwenden, was redundant wird, sobald SQLAlchemy es repariert. Ein Beispiel für eine solche Änderung ist Das spaltenbezogene COLLATE-Schlüsselwort zitiert jetzt den Collation-Namen, das die Zitierung von Datenbank-Collation-Namen hinzufügt, die groß-/kleinschreibungsempfindlich angegeben werden müssen.

  Verhaltensänderungen, bei denen keine Probleme erwartet werden, werden dennoch dokumentiert, falls unvorhergesehene Probleme auftreten. Ein Beispiel ist Die FOR UPDATE-Klausel wird sowohl innerhalb der Joined-Eager-Load-Subquery als auch außerhalb gerendert¶, was die Art und Weise ändert, wie "FOR UPDATE" in einem SELECT gerendert wird, das Joined-Eager-Loading einschließt. Diese Änderung betrifft hauptsächlich Benutzer von MySQL, da sie ein bekanntes MySQL-Problem umgeht und plötzlich Tabellenzeilen aus einer verwandten Tabelle in einem Joined-Eager-Load sperren würde, während dies auf diesem speziellen Backend zuvor nicht der Fall war.

• API-Abkündigungen - SQLAlchemy und verwandte Projekte versuchen, neue Abkündigungen nur in einem Neben-Release und nicht in einem Punkt-Release hinzuzufügen. Jede abgekündigte API sollte, soweit es in höchstem Maße möglich ist, eineDeprecationWarningauslösen, wenn diese API verwendet wird. Obwohl dies für ältere Versionen nicht immer der Fall war, ist das Ziel, dass Abkündigungen nur in Neben-Releases hinzugefügt werden und dass sie Warnungen auslösen, wenn sie verwendet werden. Dies geschieht, damit Projekte einen vollständigen Neben-Release-Zyklus haben, um von der alten API weg zu migrieren, und damit die Abkündigung leicht erkennbar ist.

• Entfernung zuvor abgekündigter APIs - Eine API, die in einem bestimmten Neben-Release abgekündigt wurde, kann bereits im nächsten Neben-Release entfernt werden, obwohl eine abgekündigte API oft mehrere Neben-Releases bestehen bleibt. In modernen Releases sollten abgekündigte APIs während der gesamten Dauer eines bestimmten Neben-Releases Warnungen ausgeben, wenn sie verwendet werden.

Haupt-Releases

Haupt-Releases beziehen sich auf den allgemeinen Reifegrad des Projekts, was ein mehrjähriger Status ist. Ein Projekt beginnt mit 0, z.B. sqlalchemy-collectd-0.0.4, was den Reifegrad von anfänglichen Alpha-Releases bis zu langzeitstabilen Releases angibt, mit der Vorstellung, dass über jedes Neben-Release hinweg wesentliche brechende Änderungen auftreten können. Bei der Hauptversion 1 gilt das Projekt als ausgereift. Hauptversion 2 und höher deuten auf wichtige neue Umstellungen für das Projekt hin, ähnlich denen von Python 2 auf Python 3.