Udgivelsesplan

From The Document Foundation Wiki
Jump to: navigation, search
This page is a translated version of the page ReleasePlan and the translation is 100% complete.

Other languages:
العربية • ‎dansk • ‎Deutsch • ‎English • ‎español • ‎français • ‎Bahasa Indonesia • ‎italiano • ‎日本語 • ‎português do Brasil • ‎română • ‎русский • ‎中文(简体)‎

Indledning

Tidsbaserede *release trains* har vist sig at fremstille Fri software. En tidsbaseret udgivelse er venter ikke på hverken funktionaliteter eller fejlrettelser -- men er baseret (så rent som muligt) på tid. Dette fremmer disciplin i introduktion af rettelser, giver forudsigelighed, og muliggør mere regelmæssig udgivelse. Det er også tilfældet, at vi nødvendigvis udgiver tidligere, og så hurtigt, trinvist udgiver fejlrettelser baseret på den forrige stabile version. Hvis du således har behov for en version med den allerhøjeste kvalitet, kan det være fornuftigt at udskyde et træk til en mindre x.1 eller x.2-udgivelse.

  • LibreOffice udgiver to-årig 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.
  • At synkronisere en tidsbaseret udgivelsesplan med det bredere Free Software-økosystem har også kæmpemæssige fordele ved at få vore nye funktionaliteter ud til brugerne så hurtigt som muligt -- med et minumum af forsinkelse i distributionsyklus. Som konsekvens sigter vi mod halvårlige udgivelser og skubber dem ovwer tid til at passe godt med marts/september-normerne.

Tidsbaserede *release trains* har vist sig at fremstille Fri software. En tidsbaseret udgivelse er venter ikke på hverken funktionaliteter eller fejlrettelser -- men er baseret (så rent som muligt) på tid. Dette fremmer disciplin i introduktion af rettelser, giver forudsigelighed, og muliggør mere regelmæssig udgivelse. Det er også tilfældet, at vi nødvendigvis udgiver tidligere, og så hurtigt, trinvist udgiver fejlrettelser baseret på den forrige stabile version. Hvis du således har behov for en version med den allerhøjeste kvalitet, kan det være fornuftigt at udskyde et træk til en mindre x.1 eller x.2-udgivelse.

  • Der er to forgreninger: Fresh (den nyeste udgave) og Still (den forrige udgave) som er beregnet for henholdvis funktions-brugere i hovedstrømmen og konservative firma-udrulninger.
  • Som et resultat får brugerne hver sjette måned en ny stor version med en bred vifte af funktionaliter, rettelser og forbedringer. Derudover får de mange mikro-udgaver med rene fejlrettelser. Den første X.Y.0-udgave er beregnet på tidlige brugere. Mere forsigtige brugere anbefales at vente på en senere X.Y.Z-udgave.

Bemærk, at de datoer, der nævnes i skemaet kan ændres, hvis der er alvorlige tekniske eller andre problemer med udgivelsen. En ekstra RC (release candidate = kandidat til udgivelse), hvis den endelige kandidat til udgivelse ikke opfylder Release Criteria (=udgivelseskriterierne). Den slags problemer kunne ændre den endelige udgivelse med en uge eller måske mere. Template:LibOReleaseLifecycle/da

7.0-udgivelsen

Basis-datoer for første udgivelse og fejlrettelses datoer
Udgivelse Frysning Publicering
7.0.0 (frysning: uge 29) Week 19 , maj 4, 2020 - maj 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 06 , feb 8, 2021 - feb 14, 2021 Week 09 , mar 1, 2021 - mar 7, 2021
7.0.6 Week 15 , apr 12, 2021 - apr 18, 2021 Week 18 , maj 3, 2021 - maj 9, 2021
Udtjent 31. maj 2021

Se også det detaljerede skema og release notes.

6.4-udgivelsen

Basis-datoer for første udgivelse og fejlrettelses datoer
Udgivelse Frysning Publicering
6.4.0 (frysning: uge 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 - mar 1, 2020
6.4.2 Week 09 , feb 24, 2020 - mar 1, 2020 Week 12 , mar 16, 2020 - mar 22, 2020
6.4.3 Week 13 , mar 23, 2020 - mar 29, 2020 Week 16 , apr 13, 2020 - apr 19, 2020
6.4.4 Week 18 , apr 27, 2020 - maj 3, 2020 Week 21 , maj 18, 2020 - maj 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
Udtjent 30. november 2020

Se også det detaljerede skema og release notes.

6.3-udgivelsen

Basis-datoer for første udgivelse og fejlrettelses datoer
Udgivelse Frysning Publicering
6.3.0 (frysning: uge 29) Week 19 , maj 6, 2019 - maj 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 - maj 3, 2020
Udtjent 29. maj 2020

Se også det detaljerede skema og release notes.

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:

  • Manday: 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

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 Linus-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 udgiveæser, herunder sikkerhedsrettelser, indtil den næste udgivelse er klar til de mest forsigtige
  • udsend ikke to builds den samme uge.

Resultatet er denne skabelon:

Overlappende udgivelser
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.

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.