Freigabe-Terminpläne

From The Document Foundation Wiki
Jump to: navigation, search

Zusammenfassung

Zeitgesteuerte Releasepläne ergeben die beste Softwarequalität in freien Projekten. Zeitgesteuert heißt, dass weder auf die Implementierung bestimmter Features (Funktionalitäten) noch auf bestimmte Bugfixes (Fehlerbeseitigungen) gewartet wird, sondern dass die Freigabe - so gut es irgend geht - rein kalenderbasiert erfolgt. Das erhöht die Disziplin beim Implementieren neuer Features sowie die Vorhersehbarkeit und erlaubt regelmäßigere Freigaben. Zwangsläufig werden wir dadurch die Entwicklungszeit verkürzen und eine Version schneller freigeben, um dieser dann in kurzen zeitlichen Abständen aufsteigende Bugfix-Versionen folgen zu lassen. Dadurch wird jemand, der höchste Ansprüche hat, in die Lage versetzt, eine sehr stabile Version auszuwählen, in dem er einfach bis zum 2. oder 3. Bugfix-Release abwartet.

Unsere Freigabezyklen mit dem Ökosystem der freien Softwarewelt zu synchronisieren hat ebenfalls große Vorteile, da wir unsere neuen Features mit minimaler Verzögerung an die Nutzer ausliefern können. Wir streben daher einen 6-monatigen Freigabezyclus an, und versuchen uns an die üblichen März/September-Termine anzugleichen.

Beachtet bitte, dass sich die im Releaseplan genannten Termine bei ernsthaften technischen oder anderen Problemen auch verschieben können. Weitere RCs (Release-Kandidaten) könnten erforderlich werden, solange ein Kandidat nicht den Releasekriterien genügt.

Zeitplan-Tabellen

Bei den Freigabe-Tabellen (siehe englische Seite, die Tabellen wurden nicht übersetzt) ist in den Grunddaten (basic dates) jeweils das "freeze"-Datum angegeben, ab welchem also die jeweilige Code-Linie nicht mehr durch neue Feature-Implementierungen verändert werden darf, sowie der geplante Veröffentlichungstermin ("publishing").

Die exakten Termine sind in den verlinkten Versions-Detailplänen ("detailed schedule") einzusehen.

Termine

Der Zeitplan basiert auf folgenden Regeln:

  • Freigabe neuer Versionen alle 6 Monate synchron zu den großen Linux-Distributionen
  • Monatliche Veröffentlichung von Bugfix-Releases nach dem Hauptrelease bis die Qualität auch konservativen Nutzern zusagt - danach kann die Freigabeperiode verlängert werden.
  • Fortsetzung der Bugfix-Releases einschließlich Sicherheitsupdates so lange, bis auch konservative Nutzer auf die nächste Version umsteigen.
  • Terminkollisionen sollten dabei möglichst vermieden werden

Das Ergebnis folgt etwa folgendem Schema:

Überlappende Versionen
Ereignis Sommer Winter
x.y feature freeze (Einfrieren der Codelinie) Anfang Juni Anfang Dezember
Version x.y.0 Anfang August Anfang Februar
Version x.y.1 Anfang September Anfang März
Version x.y.2 Anfang Oktober Anfang April
Version x.y.3 Anfang November Anfang Mai
Version x.y.4 Anfang Dezember Anfang Juni
Version x.y.5 Mitte Februar Mitte August
Version x.y.6 Mitte April Mitte Oktober


Beschleunigung der Release-Zyklen

Diese Beschleunigung der Release-Zyklen erfordert erhebliche Anstrengungen beim Release-Engineering und bei der QA. Um den Aufwand zu verringern, werden wir komplette (alle Sprachen beinhaltende) tägliche Snapshots des Master-Zweiges vorhalten, an denen die Codeverbesserungen kontinuierlich getestet werden können. Die täglichen Builds können auf folgender Seite runtergeladen werden.