Firefox-utviklere har annonsert en reduksjon i utgivelsessyklusen for nye nettleserversjoner til fire uker (tidligere versjoner ble utgitt hver 6.–8. uke). Firefox 70 vil bli utgitt i henhold til den forrige planen 22. oktober , etterfulgt av seks uker senere, 3. desember, av Firefox 71. Senere utgivelser vil følge hver fjerde uke (7. januar, 11. februar, 10. mars osv.).
Derfor vil LTS-versjonen ( Long Term Support ) bli utgitt årlig som før , og den vil bli vedlikeholdt i tre måneder etter at neste LTS-versjon er dannet. Oppdateringsoppdateringer for LTS-grenen vil bli synkronisert med de vanlige utgivelsene, og vil også bli utgitt hver fjerde uke.
Den neste ESR-utgivelsen blir Firefox 78, planlagt for juni 2020. SpiderMonkey og Tor Browser vil også bli byttet til en 4-ukers utgivelsessyklus.
Årsaken til å forkorte utviklingssyklusen er ønsket om å bringe nye funksjoner til brukerne raskere. Hyppigere utgivelser forventes å øke fleksibiliteten i planleggingen av produktutvikling og implementeringen av prioriterte endringer som oppfyller forretnings- og markedskrav.
Ifølge utviklerne gir den fire uker lange utviklingssyklusen en optimal balanse mellom hastighet i levering av nye web-API-er og sikring av kvalitet og stabilitet.
Fra første kvartal 2020 planlegger vi å sende en større versjon av Firefox hver fjerde uke. Utgivelseskadens for Firefox ESR (Extended Enterprise Support Release) vil forbli den samme.
I årene som kommer forventer vi en større ESR-utgivelse hver 12. måned med en 3-måneders støtteoverlapping mellom den nye ESR og slutten på den gamle ESRs levetid. De to neste store utgivelsene av ESR vil være ~ juni 2020 og ~ juni 2021.
Kortere utgivelsessykluser gir større fleksibilitet for å støtte produktplanlegging og prioritetsendringer på grunn av forretnings- eller markedskrav.
Med fire ukers sykluser kan vi være mer smidige og sende funksjoner raskere, mens vi bruker samme strenghet og due diligence som kreves for en stabil kvalitet av høy kvalitet.
I tillegg legger vi raskere nye funksjoner og implementering av nye web-API-er i utviklernes hender. (Dette har vi for eksempel gjort nylig med implementeringer og oppdateringer av CSS-spesifikasjoner.)
Å redusere tiden som trengs for å forberede utgivelsen vil føre til en reduksjon i testtiden for betaversjoner , nattlige versjoner og utviklerutgaver, noe som etter planen skal oppveies av hyppigere oppdateringer for testversjoner.
I stedet for å utarbeide to nye betaversjoner per uke , er planen å tilpasse den hyppige betautgivelsesordningen for betagrenen , som tidligere ble brukt for nattlige utgivelser.
For å opprettholde kvalitet og minimere risiko i en forkortet syklus, må vi:
- Forsikre deg om at Firefox ingeniørproduktivitet ikke påvirkes negativt.
- Akselerere tilbakemeldingsløyfen for regresjon fra distribusjon til deteksjon og oppløsning.
- Kunne kontrollere distribusjonen av funksjoner basert på tilgjengeligheten av versjonen.
- Sørg for riktig testing av større funksjoner som strekker seg over flere utgivelsessykluser.
- Ha klare og konsekvente avbøtende og beslutningsprosesser.
For å redusere risikoen for uforutsette problemer når man legger til noen viktige innovasjoner , vil endringene knyttet til dem rulles ut til brukere av versjonene ikke alle samtidig, men gradvis . Først vil muligheten aktiveres for en liten prosentandel av brukerne, og deretter dekkes fullstendig eller slås dynamisk av når det oppdages feil.
I tillegg vil brukere bli invitert til å delta i eksperimenter som ikke er knyttet til lanseringsforberedelsessyklusen for å teste innovasjonene og ta beslutninger om hvordan de blir inkludert i hovedteamet i Test Pilot-programmet.
Kilde: https://hacks.mozilla.org/