Chaos Mesh Release-Zyklus

Inoffizielle Beta-Übersetzung

Diese Seite wurde von PageTurner AI übersetzt (Beta). Nicht offiziell vom Projekt unterstützt. Fehler gefunden? Problem melden →

Dieses Dokument richtet sich an Chaos Mesh-Entwickler und -Mitwirkende, die Erweiterungen, Issues oder Pull Requests erstellen möchten, die auf einen bestimmten Release-Meilenstein abzielen.

Rollen

Mitwirkende/Entwickler

Von Mitwirkenden wird erwartet, dass sie sich im Release-Zyklus auf folgende Weise engagieren:

• Teilnahme an Diskussionen zur Sammlung neuer Funktionen/Erweiterungen

• Beiträge von Code/Dokumentation für Chaos Mesh

• Bei Bedarf helfen, Funktionen auszugliedern

Als Mitwirkender müssen Sie nur zwei Punkte beachten:

• Sie könnten aufgefordert werden, unvollendete Arbeiten abzuschließen oder sie aus dem Release-Branch zu entfernen

• Ihr PR wird während des "Code Freeze" möglicherweise nicht schnell in den Master-Branch gemergt

Release Manager

"Release Manager" ist ein Oberbegriff für Chaos Mesh-Mitwirkende, die für die Pflege von Release-Branches, das Tagging von Releases sowie das Erstellen und Verpacken von Chaos Mesh verantwortlich sind.

Von Release Managern wird erwartet:

• "Neue Funktionen/Erweiterungen" als GitHub Issue sammeln

• vX.Y.0 GitHub Milestone erstellen und pflegen

• Erforderliche Meetings planen und durchführen

• Die Nachverfolgungsdokumentation für den nächsten Release kontinuierlich pflegen

• Mitwirkende kontaktieren und um Hilfe bei der Fertigstellung/Ausgliederung unvollendeter Funktionen/Dokumentation bitten; oder diese selbst ausgliedern, wenn der Kontakt zu Mitwirkenden verloren geht

• Den Release-Branch erstellen

• Release Notes für die Minor-Version entwerfen

• Alpha-, Beta- und Minor-Versionen veröffentlichen

• Release-bezogene Dokumente kontinuierlich erweitern

Release Manager werden?

Chaos Mesh-Committer und -Maintainer nominieren neue Release Manager etwa in der ersten Woche des neuen Release-Zyklus. Die Nominierung wird im Slack-Kanal #chaos-mesh-maintainers bekannt gegeben. Kandidaten werden ausgewählt, wenn nicht mehr als die Hälfte der Stimmen dagegen spricht. Abschließend werden die Release Manager auf der Dokumentationswebsite und im Slack-Kanal #project-chaos-mesh angekündigt.

Versionierungsschema und Zeitplan

• Chaos Mesh veröffentlicht alle 8 Wochen eine Minor-Version vX.Y.0

• Chaos Mesh veröffentlicht mindestens alle 2 Wochen eine Preview-Version (vX.Y.0.alpha/beta-W, W>=0)

• Chaos Mesh veröffentlicht bei Bedarf Bugfix-/Patch-Versionen (vX.Y.Z, Z>0)

Release-Phasen

Ein Release-Zyklus umfasst drei Phasen:

• Normal Dev (Woche 1-5)

• Code Freeze (Woche 6-7)

• Release Week (Woche 8)

Normal Dev

Während "Normal Dev" passiert Folgendes:

• Auswahl neuer Release Manager

• Sammlung von "neuen Funktionen/Erweiterungen" für den nächsten Release

• Erstellen des vX.Y.0-Meilensteins, falls nicht vorhanden

• Programmier- und Dokumentationsarbeit

• Regelmäßige Veröffentlichung von Alpha-Versionen alle 2 Wochen

Code Freeze

Während "Code Freeze" passiert Folgendes:

• Blockieren des Mergens aller nicht zusammenhängenden PRs

• Überprüfung der "neuen Funktionen/Verbesserungen", die mit dem nächsten Release veröffentlicht werden sollen

  • Fertigstellung oder Entfernung unvollständiger Features
  • Dokumentation ist bereitgestellt (mindestens als offenes Issue auf chaos-mesh/website vorhanden)

• Erstellung des Branches release-X.Y

• Veröffentlichung von Beta-Versionen

• Vorbereitung der Release Notes

• Anlegen des vX.Y+1.0-Milestones

• Einspielen von Bugfixes bei Bedarf

• Dokumentation zum neuen Release

Die Phase "Code Freeze" beginnt in Woche 6 und endet mit der Erstellung des Branches release-X.Y.

Während des "Code Freeze" werden PRs, die nicht mit dem kommenden Minor-Release zusammenhängen, vom Merge in den Master-Branch ausgeschlossen. Nur Release-bezogene PRs dürfen in den Master-Branch gemerged werden.

Release Manager kommunizieren mit Contributors, um unvollständige Features fertigzustellen oder zu entfernen. Bei ausbleibender Kommunikation entfernen Release Manager diese Features eigenständig.

Sobald alle unvollständigen Features abgeschlossen oder zur Entfernung markiert sind, wird der release-X.Y-Branch erstellt. Der normale Merge-Prozess wird wiederaufgenommen.

Nach Entfernung unvollständiger Features veröffentlichen Release Manager die erste Beta-Version. Anschließend werden nur noch Bugfixes in den Release-Branch eingespielt. Weitere Beta-Versionen sind bei Updates möglich.

Release Manager beginnen mit der Vorbereitung der Release Notes nach Veröffentlichung der Beta-Version.

Release-Woche

Abläufe während der "Release-Woche":

• Einspielen kritischer Bugfixes oder Sicherheitsupdates bei Bedarf

• Veröffentlichung der Release-Artefakte (Helm-Charts, Container-Images etc.)

• Veröffentlichung der Release-Dokumentation

Release Manager veröffentlichen in dieser Woche die Version vX.Y.0.