Release plan

From The Document Foundation Wiki
Jump to navigation Jump to search
This page is a translated version of the page ReleasePlan and the translation is 100% complete.
Other languages:
Bahasa Indonesia • ‎Deutsch • ‎English • ‎Nederlands • ‎Türkçe • ‎dansk • ‎español • ‎français • ‎italiano • ‎português do Brasil • ‎română • ‎русский • ‎עברית • ‎العربية • ‎فارسی • ‎日本語 • ‎한국어

Introductie

Het op afgesproken tijden uitbrengen van een release blijkt in de praktijk de beste kwaliteit op te leveren bij gratis software. Er wordt dan niet gewacht op functies of de oplossing van een bepaalde fout, er wordt gekeken naar de kalender. Dit vereist discipline bij het vrijgeven van oplossingen en brengt voorspelbaarheid, er is bekend wanneer er er een release is. Dat betekent wel dat de noodzakelijke releases eerder en sneller komen als er releases nodig zijn om fouten te verhelpen, maar dat is dan op de stabiele versie. Als u dus een goede kwaliteit versie wil dan is het dus goed te overwegen te wachten tot de eerste of zelfs tweede kleine release (dus als alleen het laatste deel van het versienummer gewijzigd wordt).

  • LibreOffice brengt elk jaar twee releases uit, die synchroon lopen met andere 'Free Software' projecten (bijv. Gnome) deze zijn minstens een maand voor de grote Linux distributie releases.
  • Het afstemmen van het schema voor het uitbrengen van releases op deze andere software heeft grote voordelen. Door onze nieuwe functies zo snel mogelijk aan de gebruikers aan te bieden, zonder veel last van de distributie cyclus. We streven er naar elke zes maanden een release uit te brengen, dat proberen we in maart / september te doen.

  • Er zijn twee branches: Fresh (de nieuwste release) en Still (de vorige release), deze zijn resp. bedoeld voor de mainstream gebruikers en de wat meer behoudende of bedrijfsmatige gebruikers.
  • Gebruikers krijgen dus elke zes maanden een grote release met nieuwe of verbeterde functies, verbeterde fouten. Daarnaast krijgen ze een aantal kleine releases waarin fouten zijn opgelost. De eerste X.Y.0 release is bedoeld voor de 'early adopters'. Wij raden de wat meer voorzichtige gebruikers aan even te wachten op een zogenaamde X.Y.Z bugfix release.

Uiteraard kunnen de genoemde datums niet gehaald worden als er serieuze technische of ander problemen zijn met de release. Er kan dan een extra RC nodig zijn om te zorgen dat een versie die een release wordt, voldoet aan de release criteria.

In de wat vereenvoudigde grafiek tonen we drie releases in een periode van 24 maanden.

Toekomst
Fresh
Still

7.4 release

Basisdatums voor de initiële en de bugfix releases
Release Freeze Publishing
7.4.0 (freeze: week 30) Week 19 , mei 9, 2022 - mei 15, 2022 Week 33 , aug 15, 2022 - aug 21, 2022
7.4.1 Week 34 , aug 22, 2022 - aug 28, 2022 Week 37 , sep 12, 2022 - sep 18, 2022
7.4.2 Week 38 , sep 19, 2022 - sep 25, 2022 Week 41 , okt 10, 2022 - okt 16, 2022
7.4.3 Week 44 , okt 31, 2022 - nov 6, 2022 Week 47 , nov 21, 2022 - nov 27, 2022
7.4.4 Week 50 , dec 12, 2022 - dec 18, 2022 Week 53 , jan 2, 2023 - jan 8, 2023
7.4.5 Week 07 , feb 13, 2023 - feb 19, 2023 Week 10 , mrt 6, 2023 - mrt 12, 2023
7.4.6 Week 16 , apr 17, 2023 - apr 23, 2023 Week 19 , mei 8, 2023 - mei 14, 2023
End of Life 12 juni 2023

Lees ook het gedetailleerde schema en de release notes.

7.3 release

Basisdatums voor de initiële en de bugfix releases
Release Freeze Publishing
7.3.0 (freeze: week 02) Week 43 , okt 25, 2021 - okt 31, 2021 Week 05 , jan 31, 2022 - feb 6, 2022
7.3.1 Week 06 , feb 7, 2022 - feb 13, 2022 Week 09 , feb 28, 2022 - mrt 6, 2022
7.3.2 Week 10 , mrt 7, 2022 - mrt 13, 2022 Week 13 , mrt 28, 2022 - apr 3, 2022
7.3.3 Week 15 , apr 11, 2022 - apr 17, 2022 Week 18 , mei 2, 2022 - mei 8, 2022
7.3.4 Week 20 , mei 16, 2022 - mei 22, 2022 Week 23 , jun 6, 2022 - jun 12, 2022
7.3.5 Week 26 , jun 27, 2022 - jul 3, 2022 Week 29 , jul 18, 2022 - jul 24, 2022
7.3.6 Week 33 , aug 15, 2022 - aug 21, 2022 Week 36 , sep 5, 2022 - sep 11, 2022
7.3.7 Week 41 , okt 10, 2022 - okt 16, 2022 Week 44 , okt 31, 2022 - nov 6, 2022
End of Life 30 november 2022

Lees ook het gedetailleerde schema en de release notes.

7.2 release

Basisdatums voor de initiële en de bugfix releases
Release Freeze Publishing
7.2.0 (freeze: week 30) Week 19 , mei 10, 2021 - mei 16, 2021 Week 33 , aug 16, 2021 - aug 22, 2021
7.2.1 Week 34 , aug 23, 2021 - aug 29, 2021 Week 37 , sep 13, 2021 - sep 19, 2021
7.2.2 Week 38 , sep 20, 2021 - sep 26, 2021 Week 41 , okt 11, 2021 - okt 17, 2021
7.2.3 Week 44 , nov 1, 2021 - nov 7, 2021 Week 47 , nov 22, 2021 - nov 28, 2021
7.2.4 Week 48 , nov 29, 2021 - dec 5, 2021 Week 49 , dec 6, 2021 - dec 12, 2021
7.2.5 Week 50 , dec 13, 2021 - dec 19, 2021 Week 53 , jan 3, 2022 - jan 9, 2022
7.2.6 Week 07 , feb 14, 2022 - feb 20, 2022 Week 10 , mrt 7, 2022 - mrt 13, 2022
7.2.7 Week 16 , apr 18, 2022 - apr 24, 2022 Week 19 , mei 9, 2022 - mei 15, 2022
End of Life 12 juni 2022

Lees ook het gedetailleerde schema en de release notes.

7.1 release

Basisdatums voor de initiële en de bugfix releases
Release Freeze Publishing
7.1.0 (freeze: week 02) Week 43 , okt 19, 2020 - okt 25, 2020 Week 05 , feb 1, 2021 - feb 7, 2021
7.1.1 Week 06 , feb 8, 2021 - feb 14, 2021 Week 09 , mrt 1, 2021 - mrt 7, 2021
7.1.2 Week 10 , mrt 8, 2021 - mrt 14, 2021 Week 13 , mrt 29, 2021 - apr 4, 2021
7.1.3 Week 15 , apr 12, 2021 - apr 18, 2021 Week 18 , mei 3, 2021 - mei 9, 2021
7.1.4 Week 20 , mei 17, 2021 - mei 23, 2021 Week 23 , jun 7, 2021 - jun 13, 2021
7.1.5 Week 26 , jun 28, 2021 - jul 4, 2021 Week 29 , jul 19, 2021 - jul 25, 2021
7.1.6 Week 33 , aug 16, 2021 - aug 22, 2021 Week 36 , sep 6, 2021 - sep 12, 2021
7.1.7 Week 41 , okt 11, 2021 - okt 17, 2021 Week 44 , nov 1, 2021 - nov 7, 2021
7.1.8 Week 48 , nov 29, 2021 - dec 5, 2021 Week 49 , dec 6, 2021 - dec 12, 2021
End of Life 30 november 2021

Lees ook het gedetailleerde schema en de release notes.

7.0 release

Basisdatums voor de initiële en de bugfix releases
Release Freeze Publishing
7.0.0 (freeze: week 29) Week 19 , mei 4, 2020 - mei 10, 2020 Week 32 , aug 3, 2020 - aug 9, 2020
7.0.1 Week 33 , aug 10, 2020 - aug 16, 2020 Week 36 , aug 31, 2020 - sep 6, 2020
7.0.2 Week 38 , sep 14, 2020 - sep 20, 2020 Week 41 , okt 5, 2020 - okt 11, 2020
7.0.3 Week 43 , okt 19, 2020 - okt 25, 2020 Week 46 , nov 9, 2020 - nov 15, 2020
7.0.4 Week 48 , nov 23, 2020 - nov 29, 2020 Week 51 , dec 14, 2020 - dec 20, 2020
7.0.5 Week 07 , feb 15, 2021 - feb 21, 2021 Week 10 , mrt 8, 2021 - mrt 14, 2021
7.0.6 Week 16 , apr 19, 2021 - apr 25, 2021 Week 19 , mei 10, 2021 - mei 16, 2021
End of Life 31 mei 2021

Lees ook het gedetailleerde schema en de release notes.

6.4 release

Basisdatums voor de initiële en de bugfix releases
Release Freeze Publishing
6.4.0 (freeze: week 02) Week 42 , okt 14, 2019 - okt 20, 2019 Week 05 , jan 27, 2020 - feb 2, 2020
6.4.1 Week 06 , feb 3, 2020 - feb 9, 2020 Week 09 , feb 24, 2020 - mrt 1, 2020
6.4.2 Week 09 , feb 24, 2020 - mrt 1, 2020 Week 12 , mrt 16, 2020 - mrt 22, 2020
6.4.3 Week 13 , mrt 23, 2020 - mrt 29, 2020 Week 16 , apr 13, 2020 - apr 19, 2020
6.4.4 Week 18 , apr 27, 2020 - mei 3, 2020 Week 21 , mei 18, 2020 - mei 24, 2020
6.4.5 Week 24 , jun 8, 2020 - jun 14, 2020 Week 27 , jun 29, 2020 - jul 5, 2020
6.4.6 Week 30 , jul 20, 2020 - jul 26, 2020 Week 33 , aug 10, 2020 - aug 16, 2020
6.4.7 Week 39 , sep 21, 2020 - sep 27, 2020 Week 42 , okt 12, 2020 - okt 18, 2020
End of Life 30 november 2020

Lees ook het gedetailleerde schema en de release notes.

6.3 release

Basisdatums voor de initiële en de bugfix releases
Release Freeze Publishing
6.3.0 (freeze: week 29) Week 19 , mei 6, 2019 - mei 12, 2019 Week 32 , aug 5, 2019 - aug 11, 2019
6.3.1 Week 32 , aug 5, 2019 - aug 11, 2019 Week 35 , aug 26, 2019 - sep 1, 2019
6.3.2 Week 36 , sep 2, 2019 - sep 8, 2019 Week 39 , sep 23, 2019 - sep 29, 2019
6.3.3 Week 41 , okt 7, 2019 - okt 13, 2019 Week 44 , okt 28, 2019 - nov 3, 2019
6.3.4 Week 47 , nov 18, 2019 - nov 24, 2019 Week 50 , dec 9, 2019 - dec 15, 2019
6.3.5 Week 05 , jan 27, 2020 - feb 2, 2020 Week 08 , feb 17, 2020 - feb 23, 2020
6.3.6 Week 15 , apr 6, 2020 - apr 12, 2020 Week 18 , apr 27, 2020 - mei 3, 2020
End of Life 29 mei 2020

Lees ook het gedetailleerde schema en de release notes.

Datums

De release is op tijd gebaseerd, maar het schema gebruikt kalenderweken in plaats van exacte datums. Dat is om wat flexibel te zijn. De release kan een paar dagen vertraagt worden vanwege ernstige fouten of andere technische problemen.

De release bevat diverse beta en release kandidaat builds. Er zijn per build was acties nodig. In een ideale voortgang is het als volgt:

  • Maandag: deadline doorgeven; herinnering versturen naar ontwikkelaars, l10n mailinglijst voor de wijziging
  • Dinsdag: de tag wordt aangemaakt ter bevestiging dat de build door de unit-, subsequent-, en smoke-testen is gekomen; tag is aangekondigd op de ontwikkel- en kwaliteitszorg mailinglijsten
  • Woensdag: de builds worden geplaatst op de pre-release website; dit wordt weer aangekondigd op dezelfde mailinglijsten
  • Donderdag: de builds gaan naar de mirrors. Dit wordt op veel kanalen aangekondigd, mailinglijsten, twitter, ...
  • Vrijdag: de builds zijn beschikbaar op de official pre-release website

De final release wordt meestal op donderdag aangekondigd, enkele dagen nadat de laatste release kandidaat is uitgebracht.

Omdat er strikt wordt omgegaan met de commits op de laatste release kandidaat is er geen volledige regressie test nodig. Het wordt gebruikt als de laatste build door de benodigde testen komt. Op de mirrors wordt het alleen maar hernoemd.

Schema

De regels, waarop het schema is gebaseerd, zijn:

  • zorg elke zes maanden voor een grote release en synchroniseer het (minstens een maand ervoor) met de grote Linux distributies; het bevat altijd een een stel nieuwe functies op meerdere onderdelen, opgeloste fouten en uitbreidingen
  • breng elke maand een bugfix release uit na de hoofdrelease totdat het goed genoeg ook is voor kritische mensen, breng daarna de frequentie van uitbrengen omlaag.
  • breng releases met alleen verbeterde fouten uit, inclusief op gebied van beveiliging, totdat de volgende release geschikt voor de kritische mensen
  • breng geen builds uit in dezelfde week

In tabelvorm:

Overlappende releases
Release versie Zomer Winter
x.y bevriezen functies Jun(b) Dec(b)
x.y.0 eerste release Aug(b) Feb(b)
x.y.1 bugfix release Sep(b) Mar(b)
x.y.2 bugfix release Okt(b) Apr(b)
x.y.3 bugfix release Nov(b) Mei(b)
x.y.4 bugfix release Dec(b) Jun(b)
x.y.5 bugfix release Feb(m) Aug(m)
x.y.6 bugfix release Apr(m) Okt(m)

Hier staat (b) voor het begin van de maand, (m) voor het midden van de maand en (e) voor het einde van de maand.

Teksten bevriezen

Het releaseplan voor de eerste versie van elke grote release bevat een moment dat alle vertaalbare teksten in de "applicatie en help" bevroren worden, dus niet meer gewijzigd worden. Anders blijven de vertalers bezig met net wat bijgeschaafde teksten of teksten die achteraf toch nog nodig bleken, en dat dan nadat de teksten voor vertaling waren vrijgegeven.

Na het uitbrengen van de eerste release mogen fouten of kleine aanvullingen in de vertaalbare teksten natuurlijk wel weer worden gedaan. Al zal het toevoegen van nieuwe inhoud wel ingedeeld worden voor de volgende grote release.

Versie schema

Er zijn meerdere builds bij elke elke release. Het schema:

  • X.Y.0.0.alphaZ - Z-de alfa versie van de initiële release
  • X.Y.0.0.betaZ - Z-de beta versie van de initiële release
  • X.Y.0.Z - Z-de release kandidaat van de initiële release, de laatste (final version) wordt geplaatst op de hoofdpagina voor het downloaden
  • X.Y.1.Z - Z-de release kandidaat van de eerste bugfix release, de laatste (final version) wordt geplaatst op de hoofdpagina voor het downloaden

De voordelen hiervan zijn:

  • eenvoudig naar de gebruikers toe, alpha, beta zijn ook bij andere projecten bekende begrippen, de verwachtingen zijn dus dan in overeenstemming
  • goede sortering in RPM, Bugzilla
  • “eenvoudig” te lezen (alpha/beta teksten)

Er is over dit schema een lange discussie op de mailinglijst geweest.

Versnellen van de release cyclus

De verkorting van de cyclus van uitbrengen heeft gevolgen voor het werken met de releases en de kwaliteitsborging. Om dit qua kosten in de hand te handen zijn er complete (het bevat alle talen) dagelijkse overzichtjes van de master branch zodat er altijd gekeken kan worden naar de voortgang van het verbeteren van de code. U kunt dit bekijken en downloaden.

Het is ook de bedoeling om het build proces te automatiseren zodat de werkstroom van het releasen minder handwerk bevat en door te gaan met de 'footprint' van onze binaries kleiner te maken zodat het overzetten van een build sneller gaat zonder dat het gevolgen heeft voor de kwaliteit van de builds.

End-of-Life Releases

Een release heeft normaal gesproken een levensduur van circa 9 maanden. Wij beschouwen dat een release zijn End of Life (EOL) heeft bereikt een maand na de laatste geplande release.

Als u voor een langere termijn ondersteuning voor een release wilt hebben, kijk dan of een gecertificeerde L3 provider u dat kan aanbieden.

De releases zijn gesplitst in het ReleasePlan/Archive vanwege de hoeveelheid gegevens.