Release plan
TDF LibreOffice Document Liberation Project Blogs gemeenschap Weblate Nextcloud Redmine Ask LibreOffice Doneren
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 februari / augustus te doen.
- Er zijn twee versies beschikbaar: de nieuwste release voor technologieliefhebbers, early adopters en power users, en de vorige release - met minder functies maar langer getest - voor bedrijfsimplementaties en meer voorzichtige 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.3/X.Y.4 bugfix release.
Houd er rekening mee dat de datums die in het schema worden vermeld, kunnen worden verschoven als er ernstige technische of andere problemen zijn met de release. Een extra RC kan nodig zijn als de uiteindelijke release kandidaat een probleem heeft. Een probleem kan de uiteindelijke release met een week of langer verschuiven. Het besluit moet worden genomen in een vergadering van de Technische Stuurgroep.
In de wat vereenvoudigde grafiek tonen we drie releases in een periode van 24 maanden.
24.2 release
| Release | Freeze | Publishing |
|---|---|---|
| 24.2.0 (freeze: week 02) | Week 47 , nov 20, 2023 - nov 26, 2023 | Week 05 , jan 29, 2024 - feb 4, 2024 |
| 24.2.1 | Week 06 , feb 5, 2024 - feb 11, 2024 | Week 09 , feb 26, 2024 - mrt 3, 2024 |
| 24.2.2 | Week 10 , mrt 4, 2024 - mrt 10, 2024 | Week 13 , mrt 25, 2024 - mrt 31, 2024 |
| 24.2.3 | Week 15 , apr 8, 2024 - apr 14, 2024 | Week 18 , apr 29, 2024 - mei 5, 2024 |
| 24.2.4 | Week 20 , mei 13, 2024 - mei 19, 2024 | Week 23 , jun 3, 2024 - jun 9, 2024 |
| 24.2.5 | Week 26 , jun 24, 2024 - jun 30, 2024 | Week 29 , jul 15, 2024 - jul 21, 2024 |
| 24.2.6 | Week 33 , aug 12, 2024 - aug 18, 2024 | Week 36 , sep 2, 2024 - sep 8, 2024 |
| 24.2.7 | Week 41 , okt 7, 2024 - okt 13, 2024 | Week 44 , okt 28, 2024 - nov 3, 2024 |
| End of Life | 30 november 2024 | |
Lees ook het gedetailleerde schema en de release notes.
7.6 release
| Release | Freeze | Publishing |
|---|---|---|
| 7.6.0 (freeze: week 30) | Week 19 , mei 8, 2023 - mei 14, 2023 | Week 34 , aug 21, 2023 - aug 27, 2023 |
| 7.6.1 | Week 34 , aug 21, 2023 - aug 27, 2023 | Week 37 , sep 11, 2023 - sep 17, 2023 |
| 7.6.2 | Week 38 , sep 18, 2023 - sep 24, 2023 | Week 39 , sep 25, 2023 - okt 1, 2023 |
| 7.6.3 | Week 44 , okt 30, 2023 - nov 5, 2023 | Week 47 , nov 20, 2023 - nov 26, 2023 |
| 7.6.4 | Week 50 , dec 11, 2023 - dec 17, 2023 | Week 53 , jan 1, 2024 - jan 7, 2024 |
| 7.6.5 | Week 05 , jan 29, 2024 - feb 4, 2024 | Week 08 , feb 19, 2024 - feb 25, 2024 |
| 7.6.6 | Week 10 , mrt 4, 2024 - mrt 10, 2024 | Week 13 , mrt 25, 2024 - mrt 31, 2024 |
| 7.6.7 | Week 16 , apr 15, 2024 - apr 21, 2024 | Week 19 , mei 6, 2024 - mei 12, 2024 |
| End of Life | 12 juni 2024 | |
Lees ook het gedetailleerde schema en de release notes.
7.5 release
| Release | Freeze | Publishing |
|---|---|---|
| 7.5.0 (freeze: week 02) | Week 47 , nov 21, 2022 - nov 27, 2022 | Week 05 , jan 30, 2023 - feb 5, 2023 |
| 7.5.1 | Week 06 , feb 6, 2023 - feb 12, 2023 | Week 09 , feb 27, 2023 - mrt 5, 2023 |
| 7.5.2 | Week 10 , mrt 6, 2023 - mrt 12, 2023 | Week 13 , mrt 27, 2023 - apr 2, 2023 |
| 7.5.3 | Week 15 , apr 10, 2023 - apr 16, 2023 | Week 18 , mei 1, 2023 - mei 7, 2023 |
| 7.5.4 | Week 20 , mei 15, 2023 - mei 21, 2023 | Week 23 , jun 5, 2023 - jun 11, 2023 |
| 7.5.5 | Week 26 , jun 26, 2023 - jul 2, 2023 | Week 29 , jul 17, 2023 - jul 23, 2023 |
| 7.5.6 | Week 33 , aug 14, 2023 - aug 20, 2023 | Week 36 , sep 4, 2023 - sep 10, 2023 |
| 7.5.7 | Week 38 , sep 18, 2023 - sep 24, 2023 | Week 39 , sep 25, 2023 - okt 1, 2023 |
| 7.5.8 | Week 41 , okt 9, 2023 - okt 15, 2023 | Week 44 , okt 30, 2023 - nov 5, 2023 |
| End of Life | 30 november 2023 | |
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:
| 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.
In de praktijk moet u de tagging van de eerste release candidate in de gaten houden. Een manier om erachter te komen of RC1 is getagd, is door naar de tag-weergave van de LibreOffice-kernrepository in Gerrit te gaan en het filterveld in te voeren: libreoffice-X.Y.Z. Als de resultaten geen vermelding voor libreoffice-X.Y.Z.1 bevatten, is RC1 nog niet getagd en kunnen er nog steeds stringwijzigingen worden doorgevoerd.
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.