Gli sviluppatori di Firefox hanno annunciato una riduzione del ciclo di rilascio delle nuove versioni del browser a quattro settimane (le versioni precedenti venivano rilasciate ogni 6-8 settimane). Firefox 70 verrà rilasciato secondo il programma precedente il 22 ottobre , seguito sei settimane dopo, il 3 dicembre, da Firefox 71. I rilasci successivi avverranno ogni quattro settimane (7 gennaio, 11 febbraio, 10 marzo, ecc.).
Pertanto, la versione con supporto a lungo termine (LTS) verrà rilasciata annualmente come in precedenza e sarà mantenuta per tre mesi dopo la creazione della successiva versione LTS. Gli aggiornamenti delle patch per il ramo LTS saranno sincronizzati con i rilasci regolari e verranno rilasciati ogni quattro settimane.
La prossima versione ESR sarà Firefox 78, prevista per giugno 2020. Anche SpiderMonkey e Tor Browser passeranno a un ciclo di rilascio di 4 settimane.
La ragione per cui si sta accorciando il ciclo di sviluppo è la volontà di rendere disponibili nuove funzionalità agli utenti più rapidamente. Ci si aspetta che rilasci più frequenti aumentino la flessibilità nella pianificazione dello sviluppo del prodotto e nell'implementazione di modifiche prioritarie che soddisfino le esigenze aziendali e di mercato.
Secondo gli sviluppatori, il ciclo di sviluppo di quattro settimane consente un equilibrio ottimale tra la velocità di rilascio delle nuove API web e la garanzia di qualità e stabilità.
A partire dal primo trimestre del 2020, prevediamo di distribuire una versione principale di Firefox ogni 4 settimane. La cadenza di rilascio di Firefox ESR (Extended Support Release for Enterprise) rimarrà la stessa.
Negli anni a venire, prevediamo un importante rilascio di ESR ogni 12 mesi con una sovrapposizione di supporto di 3 mesi tra il nuovo ESR e la fine della vita utile del vecchio ESR. Le prossime due principali versioni di ESR saranno ~ giugno 2020 e ~ giugno 2021.
Cicli di rilascio più brevi offrono una maggiore flessibilità per supportare la pianificazione del prodotto e le modifiche di priorità dovute a requisiti aziendali o di mercato.
Con cicli di quattro settimane, possiamo essere più agili e distribuire le funzionalità più velocemente, applicando lo stesso rigore e due diligence necessari per un rilascio stabile e di alta qualità.
Inoltre, mettiamo le nuove funzionalità e l'implementazione di nuove API web nelle mani degli sviluppatori più rapidamente. (Questo è ciò che abbiamo fatto di recente con le implementazioni e gli aggiornamenti delle specifiche CSS, ad esempio.)
Ridurre i tempi di preparazione al rilascio comporterà una riduzione dei tempi di test per le versioni beta , le build notturne e le edizioni per sviluppatori, che sarà compensata da aggiornamenti più frequenti per le build di test.
Anziché preparare due nuove versioni beta a settimana , il piano prevede di adattare lo schema di rilascio frequente di versioni beta al ramo beta , precedentemente utilizzato per i rilasci notturni.
Per mantenere la qualità e ridurre al minimo il rischio in un ciclo ridotto, dobbiamo:
- Assicurati che la produttività dell'ingegneria di Firefox non sia influenzata negativamente.
- Accelera il ciclo di feedback della regressione dalla distribuzione al rilevamento e alla risoluzione.
- Essere in grado di controllare la distribuzione delle funzioni in base alla disponibilità della versione.
- Garantire il corretto test di funzionalità più grandi su più cicli di rilascio.
- Avere processi decisionali e di mitigazione chiari e coerenti.
Per ridurre il rischio di problemi imprevisti durante l'introduzione di innovazioni significative , le modifiche ad esse associate verranno implementate per gli utenti delle diverse versioni non tutte in una volta, ma gradualmente ; inizialmente, la funzionalità sarà attivata per una piccola percentuale di utenti e successivamente estesa a tutti gli utenti o disattivata dinamicamente in caso di rilevamento di difetti.
Inoltre, per testare le innovazioni e prendere decisioni sulla loro inclusione nel team principale del programma Test Pilot, gli utenti saranno invitati a partecipare a esperimenti non collegati al ciclo di preparazione del lancio.
Fonte: https://hacks.mozilla.org/