ReleasePlan
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Spende
Einführung
Es hat sich gezeigt, dass zeitbasierte Versionsreihen die beste Qualität an freier Software hervorbringen. Eine zeitbasierte Version ist eine, die weder auf Funktionen noch auf Fehlerbehebungen wartet - sondern (so weit wie möglich) rein zeitbasiert ist. Dies erzwingt Disziplin bei der Einführung von Korrekturen, gibt Vorhersagbarkeit und ermöglicht eine regelmäßigere Veröffentlichung. Es ist auch der Fall, dass wir notwendigerweise früher und danach schnell inkrementell Fehlerbehebungen auf der Basis der vorherigen stabilen Version veröffentlichen werden. Wenn Sie also einen Bedarf an der allerhöchsten Qualitätsversion haben, kann es sinnvoll sein, einen Umzug bis zur ersten oder vielleicht zweiten Nebenpunktversion aufzuschieben.
- LibreOffice macht halbjährliche, vorhersehbare Veröffentlichungen, die mit anderen Projekten freier Software (z.B. Gnome) synchronisiert sind und den Hauptveröffentlichungen von Linux-Distributionen mindestens einen Monat voraus sind.
- Die Synchronisierung des zeitbasierten Veröffentlichungszeitplans mit dem breiteren Ökosystem freier Software hat ebenfalls enorme Vorteile, da unsere neuen Funktionen so schnell wie möglich an die Benutzer weitergegeben werden können - mit einer minimalen Verzögerung des Verteilungszyklus. Folglich streben wir sechsmonatige Veröffentlichungen an, die wir im Februar und im August anstoßen.
- Es sind zwei Versionen verfügbar: die neueste Version für Technologie-Enthusiasten, Vorreiter und Spezialisten; und die vorherige Version - mit weniger Funktionen und intensiver getestet - für Firmen-Anwendungen und vorsichtigere User.
- Infolgedessen erhalten Benutzer alle sechs Monate eine neue Hauptversion mit einer Vielzahl an Funktionen, Korrekturen und Verbesserungen. Darüber hinaus erhalten sie viele reine Fehlerbehebungs-Mikroversionen. Die erste X.Y.0-Version ist für Erstanwender gedacht. Konservativeren Benutzern wird empfohlen, auf eine spätere X.Y.3/X.Y.4-Fehlerbehebungsversion zu warten.
Bedenke das sich die Termine im Zeitplan verschieben können wenn es ernsthafte technische oder andere Probleme mit der Veröffentlichung gibt. Es könnte ein extra RC notwendig sein wenn wenn der Veröffentlichungs-Kandidat einen Totalausfall hat. Solche Probleme können das finale Release um eine Woche oder mehr verschieben. Diese Entscheidung muss im Engineering Steering Committee getroffen werden.
Die vereinfachte Grafik unten zeigt 3 Veröffentlichungen die auf einer Zeitlinie von 24 Monaten platziert wurden.
Version 24.2
| Version | Freeze | Veröffentlichung |
|---|---|---|
| 24.2.0 (Freeze: Woche 02) | Kalenderwoche 47 , 2023-11-20 - 2023-11-26 | Kalenderwoche 05 , 2024-01-29 - 2024-02-04 |
| 24.2.1 | Kalenderwoche 06 , 2024-02-05 - 2024-02-11 | Kalenderwoche 09 , 2024-02-26 - 2024-03-03 |
| 24.2.2 | Kalenderwoche 10 , 2024-03-04 - 2024-03-10 | Kalenderwoche 13 , 2024-03-25 - 2024-03-31 |
| 24.2.3 | Kalenderwoche 15 , 2024-04-08 - 2024-04-14 | Kalenderwoche 18 , 2024-04-29 - 2024-05-05 |
| 24.2.4 | Kalenderwoche 20 , 2024-05-13 - 2024-05-19 | Kalenderwoche 23 , 2024-06-03 - 2024-06-09 |
| 24.2.5 | Kalenderwoche 26 , 2024-06-24 - 2024-06-30 | Kalenderwoche 29 , 2024-07-15 - 2024-07-21 |
| 24.2.6 | Kalenderwoche 33 , 2024-08-12 - 2024-08-18 | Kalenderwoche 36 , 2024-09-02 - 2024-09-08 |
| 24.2.7 | Kalenderwoche 41 , 2024-10-07 - 2024-10-13 | Kalenderwoche 44 , 2024-10-28 - 2024-11-03 |
| Ende der Lebensdauer | 30. November 2024 | |
Siehe auch detailed schedule und release notes.
Version 7.6
| Version | Freeze | Veröffentlichung |
|---|---|---|
| 7.6.0 (Freeze: Woche 30) | Kalenderwoche 19 , 2023-05-08 - 2023-05-14 | Kalenderwoche 34 , 2023-08-21 - 2023-08-27 |
| 7.6.1 | Kalenderwoche 34 , 2023-08-21 - 2023-08-27 | Kalenderwoche 37 , 2023-09-11 - 2023-09-17 |
| 7.6.2 | Kalenderwoche 38 , 2023-09-18 - 2023-09-24 | Kalenderwoche 39 , 2023-09-25 - 2023-10-01 |
| 7.6.3 | Kalenderwoche 44 , 2023-10-30 - 2023-11-05 | Kalenderwoche 47 , 2023-11-20 - 2023-11-26 |
| 7.6.4 | Kalenderwoche 50 , 2023-12-11 - 2023-12-17 | Kalenderwoche 53 , 2024-01-01 - 2024-01-07 |
| 7.6.5 | Kalenderwoche 05 , 2024-01-29 - 2024-02-04 | Kalenderwoche 08 , 2024-02-19 - 2024-02-25 |
| 7.6.6 | Kalenderwoche 10 , 2024-03-04 - 2024-03-10 | Kalenderwoche 13 , 2024-03-25 - 2024-03-31 |
| 7.6.7 | Kalenderwoche 16 , 2024-04-15 - 2024-04-21 | Kalenderwoche 19 , 2024-05-06 - 2024-05-12 |
| Ende der Lebensdauer | 12. Juni 2024 | |
Siehe auch detailed schedule und release notes.
Version 7.5
| Version | Freeze (Einfrieren der Codelinie) | Veröffentlichung |
|---|---|---|
| 7.5.0 (Freeze: Woche 02) | Kalenderwoche 47 , 2022-11-21 - 2022-11-27 | Kalenderwoche 05 , 2023-01-30 - 2023-02-05 |
| 7.5.1 | Kalenderwoche 06 , 2023-02-06 - 2023-02-12 | Kalenderwoche 09 , 2023-02-27 - 2023-03-05 |
| 7.5.2 | Kalenderwoche 10 , 2023-03-06 - 2023-03-12 | Kalenderwoche 13 , 2023-03-27 - 2023-04-02 |
| 7.5.3 | Kalenderwoche 15 , 2023-04-10 - 2023-04-16 | Kalenderwoche 18 , 2023-05-01 - 2023-05-07 |
| 7.5.4 | Kalenderwoche 20 , 2023-05-15 - 2023-05-21 | Kalenderwoche 23 , 2023-06-05 - 2023-06-11 |
| 7.5.5 | Kalenderwoche 26 , 2023-06-26 - 2023-07-02 | Kalenderwoche 29 , 2023-07-17 - 2023-07-23 |
| 7.5.6 | Kalenderwoche 33 , 2023-08-14 - 2023-08-20 | Kalenderwoche 36 , 2023-09-04 - 2023-09-10 |
| 7.5.7 | Kalenderwoche 38 , 2023-09-18 - 2023-09-24 | Kalenderwoche 39 , 2023-09-25 - 2023-10-01 |
| 7.5.8 | Kalenderwoche 41 , 2023-10-09 - 2023-10-15 | Kalenderwoche 44 , 2023-10-30 - 2023-11-05 |
| Ende der Lebensdauer | 30. November 2024 | |
Siehe auch detailed schedule und release notes.
Daten
Die Veröffentlichung ist zeitbasiert, aber der Zeitplan definiert Kalenderwochen anstelle von genauen Daten. Das liegt daran, dass wir immer ein bisschen flexibel sind. Die Veröffentlichung kann sich aufgrund von Blocker-Fehlern, Build-Problemen und anderen technischen Problemen um einige Tage verzögern.
Die Veröffentlichung besteht aus mehreren Beta- und Veröffentlichungskandidat Bauarten. Für jede Bauart sind mehrere Aktionen notwendig. Der ideale Arbeitsfluss sieht folgendermaßen aus:
- Montag: Bestätigungs-Deadline; Erinnerung wird an devel- und l10n-Mailing List gesendet
- Dienstag: die Daten werden zusammengestellt zu einem Paket, das Einzel-, Folge- und Stresstests beinhaltet; der Vollzug wird über die devel- und QA-Mailing Lists bekannt gegeben
- Mittwoch: die Zusammenstellungen werden auf early pre-release site hochgeladen; sie werden auf den devel- und QA-Mailing-Lists bekannt gegeben
- Donnerstag: die Zusammenstellungen werden auf den Spiegelservern hochgeladen. Sie werden auf vielen Kanälen, z. Bsp. Mailing Listen oder Twitter, veröffentlicht
- Freitag: die Zusammenstellungen sind auf Entwickler Versionen verfügbar
Die finale Veröffentlichung wird in der Regel am Donnerstag bekannt gegeben, wenige Tage nachdem der finale Veröffentlichungskandidat veröffentlicht wurde.
Wir sind sehr streng bei der Bestätigung des finalen Versionskandidaten, so dass ein kompletter Test nicht nötig ist. Er gilt als finale Version, wenn die erforderlichen Tests erfolgreich abgeschlossen wurden. Auf den Spiegel-Servern wird er lediglich umbenannt.
Zeitplan
Der Zeitplan basiert auf den folgenden Regeln:
- alle sechs Monate wird eine Hauptversion erstellt und synchronisiert (wenigstens einen Monat vor) den Hauptversionen von Linux; sie kommt immer mit vielen neuen Funktionen, Fehlerbehebungen und Weiterentwicklungen
- monatlich werden die Fehlerbehebungen veröffentlicht, bis alles gut genug selbst für die konservativstn User ist; danach erfolgen die Fehlerbehebungen seltener
- reine Fehlerbehebungen inklusive Sicherheitsverbesserungen werden eingepflegt, bis die nächste Version für die konservativsten Nutzer fertig ist
- es gibt maximal eine neue Version wöchentlich.
Das Ergebnis ist die folgende Vorlage:
| Ereignis | Sommer | Winter |
|---|---|---|
| x.y feature freeze (Einfrieren der Codelinie) | Jun(b) | Dez(b) |
| x.y.0 Erste Version | Aug(b) | Feb(b) |
| x.y.1 Fehlerkorrektur Version | Sep(b) | Mär(b) |
| x.y.2 Fehlerkorrektur Version | Okt(b) | Apr(b) |
| x.y.3 Fehlerkorrektur Version | Nov(b) | Mai(b) |
| x.y.4 Fehlerkorrektur Version | Dez(b) | Jun(b) |
| x.y.5 Fehlerkorrektur Version | Feb(m) | Aug(m) |
| x.y.6 Fehlerkorrektur Version | Apr(m) | Okt(m) |
wobei (b) meint am Beginn des Monats, (m) in der Mitte des Monatsund (e) am Ende des Monats.
Einfrieren der Texte
Die Release Pläne für die erste Version jeder Hauptversion zeigen ein "hartes Einfrieren der englischn Texte & Bildschirmmasken". Die Idee dahinter ist es, das Leben der Übersetzer leichter zu machen. Die Übersetzer sollen darauf vertrauen können, dass keine neu zu übersetzenden Texte in die Benutzeroberfläche oder die Hilfedateien während des Versionierungszeitraumes hinzukommen.
In der Praxis sollten Sie ein Auge auf die Zusammenstellung des ersten Release Candidate haben. Ein Weg dazu ist der Blick auf tag view of the LibreOffice core repository in Gerrit nach Eingabe des Filters libreoffice-X.Y.Z. Falls das Ergebnis noch keinen Eintrag unter libreoffice-X.Y.Z.1 liefert, ist der RC1 noch nicht ausgeschrieben und textuelle
Änderungen können immer noch stattfinden.
Nachdem die erste Version einer Hauptversion draussen ist, steht die Fehlerkorrektur in der grafischen Oberfläche und in der Hilfe an. Jeder komplett neuer Inhalt ist Ziel der nächsten Hauptversion.
Versionsschema
Wir machen mehrere Kompilate zu jeder neuen Version. Das folgende Schema wird dabei angewandt:
- X.Y.0.0.alphaZ - Z. Alpha-Version der ursprünglichen Veröffentlichung
- X.Y.0.0.betaZ - Z. Beta-Version der ursprünglichen Veröffentlichung
- X.Y.0.Z - Z. Version der ursprünglichen Version, der letzte RC wird als final gekennzeichnet und auf die Download-Seite gestellt.
- X.Y.1.Z - Z. Versions Kandidat der ersten Fehlerkorrektur-Version, der letzte RC wird als final gekennzeichnet und auf die Download-Seite gestellt.
Es scheint der beste Kompromiss mit den folgenden Vorteilen zu sein:
- für Normal-User leicht vertständlich, Alpha- und Beta- Kennzeichnungen sind von anderen Projekten bekannt, so dass vernünftige Erwartungen damit verbunden sind.
- korrekte alphabetische Einordnung in RPM und Bugzilla
- "einfach" zu ermitteln (Alpha und Beta Texte sind mit einem Punkt gekennzeichnet)
Es gibt eine lange Diskussion über dieses Schema in der Mailing Liste
Beschleunigung des Veröffentlichungszyklusses
Diese Beschleunigung des Veröffentlichungszyklusses bedingt einige versionstechnische und qualitative Anstrengungen. Um diese Aufwendungen klein zu halten, arbeten wir daran, komplette (d. h. für alle Sprachen) tägliche Schnappschüsse am master-Zweig bereitzustellen, um den Code kontinuierlich testen zu können. Das funktioniert bereits teilweise, wie man es hier nachvollziehen kann.
Genauso planen wir, den Kompilierungsprozess immer mehr zu automatisieren. Damit wird der manuelle Aufwand immer mehr verringert und der Fussabdruck der binären Dateien verkleinert, um eine weitaus schnellere Erstellung des Kompilationsergebnisses zu erreichen.
Veröffentlichungen am Ende des Lebenszyklusses
Eine Version hat normalerweise einen Lebenszyklus von ungefähr neun Monaten. Wir erwarten, dass eine Version sein Lebensende (EOL) einen Monat nach der letzten geplanten Version hat.
Falls eine längere Unterstützung für eine Version gewünscht wird, kann ein certified L3 provider engagiert werden, der Ihnen dabei zur Seite steht.
Wegen der großen Datenmenge werden die Versionen in ein ReleasePlan/Archive ausgelagert.