Firefox-utvecklare har meddelat en minskning av lanseringscykeln för nya webbläsarversioner till fyra veckor (tidigare versioner släpptes var 6:e–8:e vecka). Firefox 70 kommer att släppas enligt det tidigare schemat den 22 oktober , följt sex veckor senare, den 3 december, av Firefox 71. Efterföljande utgåvor kommer att följa var fjärde vecka (7 januari, 11 februari, 10 mars, etc.).
Därför kommer LTS-versionen ( Long Term Support ) att släppas årligen som tidigare och kommer att underhållas i tre månader efter att nästa LTS-version har skapats. Patchuppdateringar för LTS-grenen kommer att synkroniseras med de vanliga utgåvorna och kommer också att släppas var fjärde vecka.
Nästa ESR-utgåva blir Firefox 78, planerad till juni 2020. SpiderMonkey och Tor Browser kommer också att byta till en 4-veckors utgivningscykel.
Anledningen till att förkorta utvecklingscykeln är önskan att få nya funktioner till användarna snabbare. Mer frekventa utgåvor förväntas öka flexibiliteten i produktutvecklingsplaneringen och implementeringen av prioriterade förändringar som uppfyller affärs- och marknadskrav.
Enligt utvecklarna möjliggör den fyra veckor långa utvecklingscykeln en optimal balans mellan hastighet i leveransen av nya webb-API:er och att säkerställa kvalitet och stabilitet.
Från och med första kvartalet 2020 planerar vi att leverera en större version av Firefox var fjärde vecka. Släppkadensen för Firefox ESR (Extended Support Enterprise Release) förblir densamma.
Under de kommande åren räknar vi med en större ESR-utgåva var 12: e månad med en 3-månaders supportöverlappning mellan den nya ESR och slutet på den gamla ESR: s livslängd. De nästa två stora utgåvorna av ESR kommer att vara ~ juni 2020 och ~ juni 2021.
Kortare frigöringscykler ger större flexibilitet för att stödja produktplanering och prioritetsändringar på grund av marknads- eller affärsbehov.
Med fyra veckors cykler kan vi vara mer smidiga och leverera funktioner snabbare, samtidigt som vi använder samma noggrannhet och due diligence som krävs för en högkvalitativ och stabil release.
Dessutom sätter vi nya funktioner och implementering av nya webb-API: er i utvecklarnas händer snabbare. (Det här är vad vi nyligen har gjort med exempelvis implementeringar och uppdateringar av CSS-specifikationer.)
Att minska den tid som behövs för att förbereda sig för lansering kommer att leda till en minskning av testtiden för betaversioner , nattliga versioner och utvecklarutgåvor, vilket planeras att kompenseras av mer frekventa uppdateringar för testversioner.
Istället för att förbereda två nya betaversioner per vecka är planen att anpassa det frekventa betaversionsschemat för betagrenen , vilket tidigare användes för nattliga utgåvor.
För att bibehålla kvaliteten och minimera riskerna i en förkortad cykel måste vi:
- Se till att Firefox-produktiviteten inte påverkas negativt.
- Påskynda återkopplingsslingan för regression från distribution till upptäckt och upplösning.
- Kunna kontrollera distributionen av funktioner baserat på tillgängligheten av versionen.
- Säkerställ korrekt testning av större funktioner som spänner över flera utgivningscykler.
- Ha tydliga och konsekvent lindrings- och beslutsprocesser.
För att minska risken för oförutsedda problem när vissa betydande innovationer läggs till kommer de ändringar som är förknippade med dem att rullas ut till användare av versionerna, inte alla på en gång, utan gradvis ; till en början kommer möjligheten att aktiveras för en liten andel användare och sedan helt täckas eller dynamiskt stängas av när fel upptäcks.
Dessutom, för att testa innovationerna och fatta beslut om hur de ingår i testpilotprogrammets huvudteam, kommer användarna att inbjudas att delta i experiment som inte är kopplade till lanseringsförberedelsecykeln.
Källa: https://hacks.mozilla.org/