[ English | English (United Kingdom) | 中文 (简体, 中国) | Indonesia | 한국어 (대한민국) | español (México) | Deutsch ]

Veröffentlichungen

OpenStack hat eine 6-monatige Release-Kadenz mit verschiedenen Release-Modellen, denen Projekte folgen können.

In diesem Abschnitt können Sie:

• Verstehen Sie die verschiedenen Release-Modelle, denen OpenStack-Komponenten folgen

• Kennen Sie die Struktur der verschiedenen Release-Modelle und wie Sie effektiv darin arbeiten können, um die Zukunft von OpenStack zu beeinflussen

Freigabemodelle

OpenStack besteht aus einer Vielzahl von Projekten, die die Hauptkomponenten einer OpenStack-Cloud bilden, von Benutzer-Bibliotheken bis hin zu Lifecycle-Management-Services. Die verschiedenen Projekte sind unterschiedlicher Natur, was bedeutet, dass verschiedene Release Modelle folgen werden.

Die derzeit verfügbaren Optionen sind die folgenden:

• cycle-with-rc

• cycle-with-intermediary

• cycle-trailing

• cycle-automatic

• independent

• untagged

Release-Terminplan und Planung

Die Mehrheit der offiziellen OpenStack-Projekte folgt dem vom Release Management Team festgelegten Release-Zeitplan.

Der 6-Monatszyklus gliedert sich in drei Meilensteine und eine in der Regel einmonatige Stabilisierungsphase mit Release-Kandidaten.

Die erste Periode eines Zyklus beinhaltet einen stärkeren Fokus auf die Planung, weshalb die PTGs direkt nach den Freigaben geplant werden. Dies ist die Phase, in der Sie Ihre Spezifikationen zur Überprüfung hochladen und die Mailingliste, Projektkanäle und Meetings im IRC nutzen sollten, um alle Teile Ihres Designs zu diskutieren, die in Frage kommen.

Nach dem ersten Meilenstein konzentrieren sich einige Projekte mehr auf die Entwicklungs- und Fehlerbehebungsaktivitäten, während andere Projekte noch neue Ideen akzeptieren könnten, die in diesem Zyklus umgesetzt werden sollen.

Die dritte Periode eines Releases konzentriert sich auf den Abschluss der Implementierung und das Testen der neuen Funktionen, die während des Releases hinzugefügt wurden. Sie müssen sicherstellen, dass Sie neue Tests in Tempest hinzufügen und die Dokumentation auch vor dem dritten Meilenstein abdecken. Während dieser Phase kann sich das Kernüberprüfungsteam nur auf Funktionen mit höherer Priorität konzentrieren. Sie treffen ihre Entscheidung über die Prioritäten entweder in der PTG oder kurz danach, einige Zeit vor dem ersten Meilenstein eines Releases.

Einige Projekte haben auch unterschiedliche Termine durch einen Release-Zyklus als interne, projektspezifische Termine, wie Spec-Freeze oder Code-Freeze. Sie müssen sicherstellen, dass Sie über die Einfrierdaten informiert sind, die Sie auf der Seite Release schedule page finden.

Nach dem dritten Meilenstein konzentriert sich die Community auf die Stabilisierung der Veröffentlichung, indem sie mehr Gewicht auf das Testen und Beheben von Fehlern legt. Die Projekte, die dem Release-Zyklus folgen, haben ihre Release-Kandidaten nach dem dritten Meilenstein markiert. Es gibt keine Grenzen für die Freigabe von Kandidaten, aber das Ziel ist es, die Zahl niedrig zu halten und alle kritischen Probleme zu beheben, die durch Meilenstein-3 identifiziert wurden.

Wenn die Hauptprojekte dem Release-Zyklus folgen, wird sichergestellt, dass alle diese Projekte gleichzeitig freigegeben werden, so dass diese von nachgelagerten Teams aufgegriffen und verpackt und weiterverteilt werden können.

Stabile Zweige

Once a 6-month development cycle is completed the code for that release is branched, in git, to a stable branch. For instance, when the Stein release was completed a new branch in git, stable/stein was created.

Stable branches are kept as a safe source of fixes for high impact bugs and security issues which have been fixed, on master, since the release occurred. Given the stable nature of these branches, backports to stable branches undergo additional scrutiny when they are proposed. Proposed changes should:

• Haben ein geringes Riskio eine Regression einzuführen

• Haben einen sichtbaren Nutzen für Anwender

• Sind in sich abgeschlossen

• Be included in master and backported to all releases between master and the stable branch in question

Project teams do point releases off stable branches when enough changes accumulate in the stable branch to justify creating another release for their project.

Stable branches proceed through different levels of maintenance as they age.

Zustand	Zeitfenster	Zusammenfassung
Unterstützt	Ungefähr 18 Monate	All appropriate bug fixes accepted and releases are produced.
Erweiterte Unterstützung	While there are community members maintaining it.	All appropriate bug fixes accepted. No releases are produced and there is reduced CI commitment.
Nicht unterstützt	6 months from the time the branch is made unmaintained.	The branch is under Extended Maintenance rules, but there are no maintainers.
End of Life (EOL)	Nicht anwendbar	Branch is no longer accepting Changes.

Before the Ocata release the Maintained and Extended Maintenance phases were only 6 months long. This meant that each release went End of Life after 18 months. It was determined that this practice was not beneficial for distributors or users of OpenStack. As a result the Maintained state was updated to last 18 months and the Extended Maitenance time frame was made flexible increasing the number of stable branches still accepting fixes.

Der Status aller OpenStack Versionen kann auf der OpenStack Releases Webseite angesehen werden.

For more detailed information on Stable Branches and their maintenance phases see the Stable Branches page.