Release plan

    From The Document Foundation Wiki
    This page is a translated version of the page ReleasePlan and the translation is 100% complete.

    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.

    Toekomst
    Fresh
    Still

    24.2 release

    Basisdatums voor de initiële en de bugfix releases
    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

    Basisdatums voor de initiële en de bugfix releases
    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

    Basisdatums voor de initiële en de bugfix releases
    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:

    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.

    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.