ReleasePlan/de

    From The Document Foundation Wiki
    This page is a translated version of the page ReleasePlan and the translation is 47% complete.
    Outdated translations are marked like this.

    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 Laufe der Zeit anstoßen, um sie gut an die März/September-Normen anzupassen.
    • Es gibt 2 Zweige: Fresh (Die neueste Veröffentlichung) und Still (Die vorherige Veröffentlichung), welche jeweils für Mainstream-Benutzer und konservative, gemeinsame Entwicklungen angelegt sind.
    • 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.Z-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 nicht den Veröffentlichungs-Kriterien entspricht. Solche Probleme können das finale Release um eine Woche oder mehr verschieben.

    Die vereinfachte Grafik unten zeigt 3 Veröffentlichungen die auf einer Zeitlinie von 24 Monaten platziert wurden.

    Zukunft
    Fresh
    Still

    24.2 release

    Basic dates for the initial and bugfix releases
    Release Freeze Publishing
    24.2.0 (freeze: week 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
    End of Life November 30, 2024

    7.6 release

    Basic dates for the initial and bugfix releases
    Release Freeze Publishing
    7.6.0 (freeze: week 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
    End of Life June 12, 2024

    Siehe auch detailed schedule und release notes.


    7.5 Release

    Grundlegende Termine für die anfängliche und Fehlerbehebungs-Veröffentlichungen.
    Release Freeze Publishing
    7.5.0 (freeze: week 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
    End of Life November 30, 2023

    Siehe auch detailed schedule und release notes.

    Dates

    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:

    • Monday: commit deadline; reminder is sent to devel, l10n mailing list before it happens
    • Tuesday: the tag is created on a commit that builds and passes unit-, subsequent-, and smoke-tests; tag is announced on the devel and qa mailing lists
    • Wednesday: builds are uploaded on the early pre-release site; they are announced on the devel and qa mailing lists
    • Thursday: builds are uploaded on mirrors. They are announced via many channels, e.g. mailing lists, twitter
    • Friday: builds are available via the official pre-release site

    Die finale Veröffentlichung wird in der Regel am Donnerstag bekannt gegeben, wenige Tage nachdem der finale Veröffentlichungskandidat veröffentlicht wurde.

    Note that we are very strict about commits to the final release candidate, so full regression test is not needed. It is used as the final build when it passes the needed tests. It is just renamed on mirrors.

    Zeitplan

    Der Zeitplan basiert auf den folgenden Regeln:

    • do the major release every six months and synchronize it (at least one month ahead) with major Linux distributions; it always comes with a wide range of features, fixes, and enhancements
    • do a pure bugfix release every month after the main release until it is good enough even for the most conservative people; do it less frequently afterwards
    • do pure bugfix releases, including security fixes, until the next release is ready for most conservative people
    • do not do two builds the same week.

    Das Ergebnis ist die folgende Vorlage:

    Ineinandergreifende Veröffentlichungen
    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 bugfix release Sep(b) Mär(b)
    x.y.2 bugfix release Okt(b) Apr(b)
    x.y.3 bugfix release Nov(b) Mai(b)
    x.y.4 bugfix release Dez(b) Jun(b)
    x.y.5 bugfix release Feb(m) Aug(m)
    x.y.6 bugfix release Apr(m) Okt(m)

    Where (b) means the beginning of the month, (m) means the middle of the month and (e) means the end of the month.

    String freeze

    The release plans for the first version of each major release indicate a "hard English string & UI freeze". The idea is to make the lives of translators easier. The translators should be able to trust that no new translatable strings are added into the UI or Help files between the period of the string freeze and release.

    In practice, you should keep an eye on the tagging of the first release candidate. One way to find out, if RC1 has been tagged is to visit the tag view of the LibreOffice core repository in Gerrit and input into the filter field: libreoffice-X.Y.Z. If the results do not contain any entry for libreoffice-X.Y.Z.1, RC1 has not yet been tagged and string changes can still be committed.

    After the first version of a major release is out, correcting mistakes in the UI and Help strings is fine. Any completely new content should target the next major release.

    Versionsschema

    We do several builds around each release. The following versioning scheme is used:

    • 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 - Zth release candidate of the initial release, last rc is considered as final and put on the main download page
    • X.Y.1.Z - Zth release candidate of the 1st bugfix release, last rc is considered as final and put on the main download page

    Es scheint der beste Kompromiss mit den folgenden Vorteilen zu sein:

    • easy to understand for normal users, alpha, beta flags are known from other projects, so they set reasonable expectations
    • correct alphabetical sorting in RPM, Bugzilla
    • “easy” to parse (alpha/beta strings delimited by dot)

    There was a long discussion about this scheme on the mailing list.

    Beschleunigung des Veröffentlichungszykluses

    This acceleration of the release cycle involves some considerable release engineering and QA effort. To reduce the cost of these, we work to provide complete (ie. containing all languages) daily snapshots of the master branch to allow continual testing of code improvements. This works partially already, as can be seen/downloaded from here.

    Similarly, we plan to increasingly automate the build process to allow a much lower-touch release flow, and to continue to shrink the footprint of our binaries to allow far more rapid transfer of product-equivalent builds.

    End-of-Life Releases

    A release normally has a lifetime of around nine months. We consider a release to have reached its End of Life (EOL) one month after the last planned release.

    If you want longer term support for a release, you’re encouraged to engage any certified L3 provider who could provide you with the service.

    Because of the amount of data, the releases were split out to ReleasePlan/Archive.