Udgivelsesplan
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
Indledning
Tidsbaserede udgivelser har vist sig at producere den bedste kvalitet af gratis software. En tidsbaseret udgivelse er en, der ikke venter på funktioner eller fejlrettelser, men er baseret (så rent som muligt) på tid. Dette gennemtvinger disciplin i at introducere rettelser, giver forudsigelighed og giver mulighed for mere regelmæssige udgivelser. Det er også sådan, at vi nødvendigvis vil frigive tidligere, og derefter hurtigt, trinvist, fejlrettelsesudgivelser baseret på den tidligere stabile udgivelse. Så hvis du har et behov for den allerhøjeste kvalitet udgivelse, kan det være fornuftigt at udsætte et træk til den første eller måske anden mindre punktudgivelse.
- LibreOffice udgiver halvårlige forudsigelige udgivelser, som er synkroniseret med andre Frie software-projekter (fx Gnome) og mindst en måned før udgivelse af større Linux-distributioner.
- Synkronisering af den tidsbaserede udgivelsesplan med det bredere fri software-økosystem har også store fordele ved at få vores nye funktioner ud til brugerne så hurtigt som muligt med et minimum af forsinkelse i distributionscyklussen. Som følge heraf sigter vi mod seks månedlige udgivelser i februar og august.
- Der er to tilgængelige versioner: den seneste udgivelse til teknologientusiaster, tidlige brugere og superbrugere, og den tidligere udgivelse - med færre funktioner, men testet i længere tid - til virksomhedsimplementeringer og mere forsigtige brugere.
- Som et resultat får brugerne en ny større udgivelse hvert halve år med en lang række funktioner, rettelser og forbedringer. De vil også modtage mange fejlrettende mikroudgivelser. Den første X.Y.0-udgivelse er beregnet til tidlige brugerne. Mere konservative brugere rådes til at vente på en senere X.Y.3/X.Y.4 bugfix-udgivelse.
Bemærk, at datoerne nævnt i tidsplanen kan blive flyttet, hvis der er alvorlige tekniske eller andre problemer med udgivelsen. En ekstra RC kan være nødvendig, hvis den endelige udgivelseskandidat har et katastrofalt problem. Et sådant problem kan flytte den endelige udgivelse med en uge eller mere. Beslutningen bør træffes på et møde i Engineering Steering Committee.
Den forenklede grafik herunder viser tre udgivelser placeret på en 24-måneders tidslinje.
25.2 release
| Release | Freeze | Publishing |
|---|---|---|
| 25.2.0 (freeze: week 02) | Week 47 , nov. 18, 2024 - nov. 24, 2024 | Week 05 , jan. 27, 2025 - feb. 2, 2025 |
| 25.2.1 | Week 06 , feb. 3, 2025 - feb. 9, 2025 | Week 09 , feb. 24, 2025 - mar. 2, 2025 |
| 25.2.2 | Week 10 , mar. 3, 2025 - mar. 9, 2025 | Week 13 , mar. 24, 2025 - mar. 30, 2025 |
| 25.2.3 | Week 15 , apr. 7, 2025 - apr. 13, 2025 | Week 18 , apr. 28, 2025 - maj 4, 2025 |
| 25.2.4 | Week 20 , maj 12, 2025 - maj 18, 2025 | Week 23 , jun. 2, 2025 - jun. 8, 2025 |
| 25.2.5 | Week 26 , jun. 23, 2025 - jun. 29, 2025 | Week 29 , jul. 14, 2025 - jul. 20, 2025 |
| 25.2.6 | Week 33 , aug. 11, 2025 - aug. 17, 2025 | Week 36 , sep. 1, 2025 - sep. 7, 2025 |
| 25.2.7 | Week 41 , okt. 6, 2025 - okt. 12, 2025 | Week 44 , okt. 27, 2025 - nov. 2, 2025 |
| End of Life | November 30, 2025 | |
See also the detailed schedule and the release notes.
24.8 release
| Release | Freeze | Publishing |
|---|---|---|
| {{{5}}} | Week 30 , jul. 22, 2024 - jul. 28, 2024 | Week 34 , aug. 19, 2024 - aug. 25, 2024 |
| 24.8.1 | Week 34 , aug. 19, 2024 - aug. 25, 2024 | Week 37 , sep. 9, 2024 - sep. 15, 2024 |
| 24.8.2 | Week 38 , sep. 16, 2024 - sep. 22, 2024 | Week 41 , okt. 7, 2024 - okt. 13, 2024 |
| 24.8.3 | Week 43 , okt. 21, 2024 - okt. 27, 2024 | Week 46 , nov. 11, 2024 - nov. 17, 2024 |
| 24.8.4 | Week 48 , nov. 25, 2024 - dec. 1, 2024 | Week 51 , dec. 16, 2024 - dec. 22, 2024 |
| 24.8.5 | Week 5 , jan. 27, 2025 - feb. 2, 2025 | Week 8 , feb. 17, 2025 - feb. 23, 2025 |
| 24.8.6 | Week 10 , mar. 3, 2025 - mar. 9, 2025 | Week 13 , mar. 24, 2025 - mar. 30, 2025 |
| 24.8.7 | Week 16 , apr. 14, 2025 - apr. 20, 2025 | Week 19 , maj 5, 2025 - maj 11, 2025 |
| End of Life | June 12, 2025 | |
See also the detailed schedule and the release notes.
24.2 udgivelsen
| Frigivelse | Frysning | Udgivelse |
|---|---|---|
| 24.2.0 (frysning: uge 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 - mar. 3, 2024 |
| 24.2.2 | Week 10 , mar. 4, 2024 - mar. 10, 2024 | Week 13 , mar. 25, 2024 - mar. 31, 2024 |
| 24.2.3 | Week 15 , apr. 8, 2024 - apr. 14, 2024 | Week 18 , apr. 29, 2024 - maj 5, 2024 |
| 24.2.4 | Week 20 , maj 13, 2024 - maj 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 |
| Udtjent | 30. november 2024 | |
Se også den detaljerede tidsplan og udgivelsesbemærkningerne.
7.6-udgivelsen
| Frigivelse | Frysning | Udgivelse |
|---|---|---|
| 7.6.0 (frysning: uge 30) | Week 19 , maj 8, 2023 - maj 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 , mar. 4, 2024 - mar. 10, 2024 | Week 13 , mar. 25, 2024 - mar. 31, 2024 |
| 7.6.7 | Week 16 , apr. 15, 2024 - apr. 21, 2024 | Week 19 , maj 6, 2024 - maj 12, 2024 |
| Udtjent | 12. juni 2024 | |
Se også det detaljerede skema og udgivelsesnoter.
7.5-udgivelsen
| Frigivelse | Frysning | Udgivelse |
|---|---|---|
| 7.5.0 (frysning: uge 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 - mar. 5, 2023 |
| 7.5.2 | Week 10 , mar. 6, 2023 - mar. 12, 2023 | Week 13 , mar. 27, 2023 - apr. 2, 2023 |
| 7.5.3 | Week 15 , apr. 10, 2023 - apr. 16, 2023 | Week 18 , maj 1, 2023 - maj 7, 2023 |
| 7.5.4 | Week 20 , maj 15, 2023 - maj 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 |
| Udtjent | 30. november 2023 | |
Se også det detaljerede skema og udgivelsesnoter.
Datoer
Denne udgave er tidsbaseret, men skemaet definerer kalenderuger i stedet for præscise datoer. Det er fordi, vi altid er lidt felksible. Udgivelsen kan blive forsinket nogle få dage på grund af blokeringsfejl, build-problemer og andre tekniske problemer.
Udgivelsen består af adskillige beta-udgaver og udgivelseskandidater. Der er behov for adskillige handlinger for hver udgivelse. Den ideelle arbejdsgang ser sådan ud:
- Mandag: deadline for forpligtelse; påmindelse sendes til mail-listerne devel (udvikling) og l10n (lokalisering), før det sker
- Tirsdag: der oprettes et mærke (tag) på en forpligtelse, der som bygger og passerer enheds-, følge- og røgtests; mærket annonceres på maillisterne devel (udvikling) og qa (kvalitetskontrol)
- Onsdag: builds uploades på early pre-release-stederne; de annonceres på maillisterne devel (udvikling) og qa (kvalitetskontrol)
- Torsdag: builds uploades til spejlene. De annonceres på mange kannaler, fx
maillister og twitter
- Fredag: builds er tilgængelige på official pre-release-stederne
Den endelige udgave annonceres sædvanligvis om torsdagen, nogle få dage efter, at den endelige udgivelseskandidater er frigivet.
Bemærk, at vi er meget strenge med hensyn til forpligtelser til den endelige udgivelseskandidat, så en komplet regressionstest er ikke nødvendig. Den bruges som endelig udgave, når den passerer de nødvendige tests. Den omdøbes blot på spejlene.
Skema
Skemaet er baseret på disse regler:
- udsend en stor udgivelse hver sjette måned og synkroniser den (mindst en måned før) med større Linux-distributioner; den har altid en bred vifte af funktionaliteter, rettelser og forbedringer
- udsend en ren fejlrettet udgave hver måned efter hoved-udgivelsen, indtil den er god nok til selv de mest forsigtige folk; udsend den sjældnere derefter
- udsend rene fejlrettede udgivelser, herunder sikkerhedsrettelser, indtil den næste udgivelse er klar til de mest forsigtige
- udsend ikke to builds den samme uge.
Resultatet er denne skabelon:
| Begivendhed | Sommer | Winter |
|---|---|---|
| x.y frysning af funktionaliteter | juni (b) | Dec (b) |
| x.y.0 første udgivelse | Aug(b) | Feb(b) |
| x.y.1 fejlrettet udgivelse | Sep(b) | Mar(b) |
| x.y.2 fejlrettet udgivelse | Okt(b) | Apr(b) |
| x.y.3 fejlrettet udgivelse | Nov(b) | Maj(b) |
| x.y.4 fejlrettet udgivelse | Dec(b) | Jun(b) |
| x.y.5 fejlrettet udgivelse | Feb(m) | Aug(m) |
| x.y.6 fejlrettet udgivelse | Apr(m) | Okt(m) |
Hvor (b) betyder begyndelsen af måneden, (m) betyder midt i måneden og (s) betyder i slutningen af måneden.
Frysning af strenge
Udgivelsesplanerne for den første version af hver størrelse udgivelse angiver en "fastfrysning af engelske strenge og brugerflade". Hensigten er at gøre oversætternes liv lettere. Oversætterne bør kunne stole på, at der tilføjes nu strenge til oversættelse i brugerfladen eller hjælp-filerne i tiden mellem frysning af strengene og udgivelsen.
I praksis bør du holde øje med taggingen af den første udgivelseskandidat. En måde at finde ud af, om RC1 er blevet tagget, er at besøge tag-visningen af LibreOffice-kernelageret i Gerrit og indtaste i filterfeltet: libreoffice-X.Y.Z. Hvis resultaterne ikke indeholder nogen indgang for libreoffice-X.Y.Z.1, er RC1 endnu ikke blevet tagget, og strengændringer kan stadig foretages.
Efter den første version af en større udgivelse er frigivet er det godt at rette fejl i brugerfladen og hjælp-strengene. Ethvert fuldstændigt nyt indhold bør målrettes den næste større udgivelse.
Versionsskema
Vi fremstiller flere builds i forbindelse med hver udgivelse. Det følgende versionsskema anvendes:
- X.Y.0.0.alphaZ - Z'nde alfa-version af den forberende udgivelse
- X.Y.0.0.betaZ - Z'nde beta-version af den forberende udgivelse
- X.Y.0.Z - Z'nde udgivelseskandidat af den forberedende udgivelse; den sidste rc (udgivelseskandidat) anses som den endelige version og lægges på hoved-download-siden
- X.Y.1.Z - Z'nde udgivelseskandidat af den første fejlrettede udgivelse; den sidste rc (udgivelseskandidat) anses som den endelige version og lægges på hoved-download-siden
Det ligner det bedste kompromis med disse fordele
- let at forstå for almindelige brugere; alfa- og beta-flag kendes fra andre projekter og giver derfor fornuftige forventninger
- korrekt alfabetisk sortering i RPM, Bugzilla
- "let" at fortolke (alfa/beta-strenge er adskilt af et punktum)
Der var en lang diskussion om dette skema på maillisten.
Acceleration af udgivelsescyklus
Denne acceleration af udgivelsescyklus medfører et betragteligt arbejde for udgivelsesingeniørerne og indsats fra kvalitetskontrollen. For at nedbringe disse omkostninger arbejder vi på at levere fuldstændige (dvs. med alle sprog) daglige billeder af master-grenen for at tillade løbende afprøvning af forbedringer af koden. Dette fungerer allerede delvist, som det kan ses/downloades her(fra).
Vi planlægger ligledes at gradvis at automatisere build-processen for at tillade et udgivelsesforløb med meget mindre berøring, og for at formindske vore binære filers fodaftryk for at tillade meget hurtigere overførsel af produkt-værdige builds.
Udtjente udgivelser
En udgivelse har normalt en levetid på omkring ni måneder. Vi regner med, at en udgivelse har nået slutningen af sin levetid (EOL = End of Life) en måned efter den sidste planlagte udgivelse.
Hvis du ønsker længere support på en udgivelse, opfordres du til at engagere en vilkårlig certificeret L3 leverandør, som kan levere dig denne tjeneste.
På grund af datamængden blev udgivelserne lagt ud på ReleasePlan/Archive.