Piano di rilascio

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

Introduzione

I processi di rilascio a scadenze prestabilite hanno dimostrato di produrre Software Libero di miglior qualità. Un rilascio a date predefinite non si ferma per aspettare l'inserimento né di funzionalità, né di correzioni di bug - ma si basa esclusivamente (per quanto possibile) sul tempo. Questo rafforza la disciplina nell'introduzione delle correzioni, conferisce prevedibilità e permette rilasci più regolari. Ciò comporta la necessità di rilasciare prima e con rapidità, dei rilasci incrementali per la correzione di bug, basati sulla precedente versione stabile. Quindi se avete bisogno di una versione di qualità elevata, potrebbe essere sensato attendere il primo, o anche il secondo, rilascio minore prima di effettuare l'aggiornamento.

  • LibreOffice rilascia delle nuove versioni, due volte all'anno, con tempistiche prevedibili, in sincrono con altri progetti di Software Libero (per es. Gnome), ciò avviene almeno un mese prima del rilascio delle nuove versioni delle maggiori distribuzioni Linux.
  • anche la sincronizzazione delle scadenze dei rilasci con quelle del più ampio ecosistema del Software Libero presenta grandi vantaggi, mettendo a disposizione degli utenti le nuove funzionalità il prima possibile, con un minimo intervallo nel ciclo di distribuzione. Conseguentemente, puntiamo ad avere dei rilasci semestrali, che nel tempo verranno leggermente spostati in modo da allinearli alla regola Marzo/Settembre.

I processi di rilascio a scadenze prestabilite hanno dimostrato di produrre Software Libero di miglior qualità. Un rilascio a date predefinite non si ferma per aspettare l'inserimento né di funzionalità, né di correzioni di bug - ma si basa esclusivamente (per quanto possibile) sul tempo. Questo rafforza la disciplina nell'introduzione delle correzioni, conferisce prevedibilità e permette rilasci più regolari. Ciò comporta la necessità di rilasciare prima e con rapidità, dei rilasci incrementali per la correzione di bug, basati sulla precedente versione stabile. Quindi se avete bisogno di una versione di qualità elevata, potrebbe essere sensato attendere il primo, o anche il secondo, rilascio minore prima di effettuare l'aggiornamento.

  • esistono 2 rami: Fresh (l'ultima versione) e Still (la versione precedente), che sono pensati rispettivamente: il primo, per gli utenti che desiderano avere le ultime funzionalità e, il secondo, per gli utenti più conservativi e le installazioni in ambito aziendale.
  • di conseguenza agli utenti avranno una nuova versione principale ogni sei mesi, con un'ampia gamma di nuove funzionalità, correzioni e miglioramenti. In aggiunta avranno diverse altre micro versioni destinate puramente alla correzione di bug. La prima versione X.Y.0 è destinata ad utenti all'avanguardia (early adopters). Per gli utenti più prudenti è consigliabile attendere il rilascio di una successiva versione di bugfix X.Y.Z.

Si precisa che le date indicate nel programma potrebbero slittare nel caso di seri problemi tecnici o di altro tipo riscontrati con una versione. Potrebbe rendersi necessaria una RC aggiuntiva, nel caso in cui la release candidate finale non rispetti i Requisiti di Rilascio. Problemi di questo tipo potrebbero ritardare il rilascio finale di una settimana o più.

versione 7.0

Date di massima per il rilascio delle versioni iniziale e di bugfix
Versione Congelamento Pubblicazione
7.0.0 (congelamento: settimana 29) Week 19 , mag 4, 2020 - mag 10, 2020 Week 32 , ago 3, 2020 - ago 9, 2020
7.0.1 Week 33 , ago 10, 2020 - ago 16, 2020 Week 36 , ago 31, 2020 - set 6, 2020
7.0.2 Week 38 , set 14, 2020 - set 20, 2020 Week 41 , ott 5, 2020 - ott 11, 2020
7.0.3 Week 43 , ott 19, 2020 - ott 25, 2020 Week 46 , nov 9, 2020 - nov 15, 2020
7.0.4 Week 48 , nov 23, 2020 - nov 29, 2020 Week 51 , dic 14, 2020 - dic 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 , mag 3, 2021 - mag 9, 2021
Fine vita 31 maggio 2021

Consultate anche il programma dettagliato e le note di rilascio.

versione 6.4

Date di massima per il rilascio delle versioni iniziale e di bugfix
Versione Congelamento Pubblicazione
6.4.0 (congelamento: settimana 02) Week 42 , ott 14, 2019 - ott 20, 2019 Week 05 , gen 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 - mag 3, 2020 Week 21 , mag 18, 2020 - mag 24, 2020
6.4.5 Week 24 , giu 8, 2020 - giu 14, 2020 Week 27 , giu 29, 2020 - lug 5, 2020
6.4.6 Week 30 , lug 20, 2020 - lug 26, 2020 Week 33 , ago 10, 2020 - ago 16, 2020
6.4.7 Week 39 , set 21, 2020 - set 27, 2020 Week 42 , ott 12, 2020 - ott 18, 2020
Fine vita 30 novembre 2020

Consultate anche il programma dettagliato e le note di rilascio.

versione 6.3

Date di massima per il rilascio delle versioni iniziale e di bugfix
Versione Congelamento Pubblicazione
6.3.0 (congelamento: settimana 29) Week 19 , mag 6, 2019 - mag 12, 2019 Week 32 , ago 5, 2019 - ago 11, 2019
6.3.1 Week 32 , ago 5, 2019 - ago 11, 2019 Week 35 , ago 26, 2019 - set 1, 2019
6.3.2 Week 36 , set 2, 2019 - set 8, 2019 Week 39 , set 23, 2019 - set 29, 2019
6.3.3 Week 41 , ott 7, 2019 - ott 13, 2019 Week 44 , ott 28, 2019 - nov 3, 2019
6.3.4 Week 47 , nov 18, 2019 - nov 24, 2019 Week 50 , dic 9, 2019 - dic 15, 2019
6.3.5 Week 05 , gen 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 - mag 3, 2020
Fine vita 29 maggio 2020

Consultate anche il programma dettagliato e le note di rilascio.

Date

I rilasci avvengono a scadenza, ma il programma stabilisce le settimana del calendario e non le date esatte. Questo perché siamo sempre un po' flessibili. Il rilascio può essere posticipato di qualche giorno a causa di bug bloccanti, problemi in fase di compilazione o altre questioni tecniche.

I rilasci sono costituiti dalla compilazione di diverse versioni beta e release candidate. Per ciascuna compilazione sono necessarie diverse operazioni. Il flusso di lavoro ideale è il seguente:

  • Lunedì: scadenza per i commit; prima che si verifichi, vengono inviati degli avvisi alle mailing list degli sviluppatori e dei traduttori
  • Martedì: viene creato un tag su di un commit in grado di essere compilato e di passare i test: unit, subsequent e smoke; il tag viene annunciato sulle mailing list degli sviluppatori e della certificazione di qualità (qa)
  • Mercoledì: le versioni compilate vengono caricate sul sito delle prime pre-release; vengono annunciate sulle mailing list degli sviluppatori e della certificazione di qualità (qa)
  • Giovedì: le versioni compilate vengono caricate sui mirror. Vengono annunciate attraverso molti canali, come ad esempio mailing list, twitter
  • Venerdì: le versioni compilate vengono rese disponibili sul sito delle pre-release ufficiali

La versione finale di solito viene annunciata di Sabato, qualche giorno dopo il rilascio dell'ultima release candidate.

Si precisa che siamo molto restrittivi con i commit all'ultima release candidate, perciò un test di tipo full regression non è necessario. Se supera tutti i test previsti viene utilizzata come versione finale. Viene semplicemente rinominata sui mirror.

Programma

Il programma è fondato sulle seguenti regole:

  • rilasciare la versione principale ogni sei mesi e sincronizzarla (almeno un mese prima) con le principali distribuzioni Linux; introduce sempre un'ampia gamma di funzionalità, correzioni e miglioramenti;
  • rilasciare versioni di pura correzione di bug ogni mese a partire dal rilascio della versione principale e fino a che non sia sufficientemente stabile anche per le persone più conservative, dopodiché ridurne la frequenza;
  • rilasciare versioni di pura correzione di bug, comprese le correzioni relative alla sicurezza, fino a che la versione successiva non sarà pronta per gli utenti più conservativi;
  • non effettuare due compilazioni nella stessa settimana.

Il risultato è quello del seguente schema:

Incrocio dei rilasci
Evento Estate Inverno
x.y Congelamento delle funzionalità Giu (i) Dic (i)
x.y.0 rilascio versione principale Ago (i) Feb (i)
x.y.1 versione di bugfix Set (i) Mar (i)
x.y.2 versione di bugfix Ott (i) Apr (i)
x.y.3 versione di bugfix Nov (i) Mag (i)
x.y.4 versione di bugfix Dic (i) Giu (i)
x.y.5 versione di bugfix Feb (m) Ago (m)
x.y.6 versione di bugfix Apr (m) Ott (m)

Dove (i) indica l'inizio del mese, (m) significa la metà del mese e (f) significa la fine del mese.

Congelamento delle stringhe di testo

Il piano di rilascio di ogni versione principale prevede un "congelamento" delle stringhe di testo in inglese presenti nel codice e nell'interfaccia grafica. Lo scopo è quello di rendere più agevole il lavoro dei traduttori. I traduttori devono avere la certezza che, nell'interfaccia grafica e nei file dell'Aiuto in linea, non verranno introdotte nuove stringhe da tradurre nel periodo intercorrente tra il periodo di congelamento delle stringhe ed il rilascio.

Dopo che il primo rilascio della versione principale è stato effettuato, sono ammesse le correzioni degli errori nell'interfaccia grafica e nell'Aiuto. Qualsiasi contenuto completamente nuovo andrà indirizzato alla successiva versione principale.

Schema di rilascio

Per ogni rilascio vengono effettuate diverse compilazioni, per le quali viene usato il seguente schema di versione:

  • X.Y.0.0.alphaN - N-esima versione alpha del rilascio iniziale
  • X.Y.0.0.betaN - N-esima versione beta del rilascio iniziale
  • X.Y.0.N - N-esima release candidate del rilascio iniziale, l'ultima RC è ritenuta la versione finale e resa disponibile sulla pagina principale di download
  • X.Y.1.N - N-esima release candidate della 1a bugfix release, l'ultima RC è ritenuta la versione finale e resa disponibile sulla pagina principale di download

Questo sembra essere il miglior compromesso e presenta i seguenti vantaggi:

  • è facile da capire per gli utenti comuni, i termini alpha e beta sono già noti da altri progetti e corrispondono alle aspettative;
  • ordine alfabetico corretto in RPM e Bugzilla
  • “facile” da processare (le stringe alpha/beta sono separate da punti)

Sulla mailing list c'è stata una lunga discussione in merito all'adozione di questo schema.

Accelerazione del ciclo di rilascio

Questa accelerazione del ciclo di rilascio comporta un considerevole sforzo ingegneristico e di controllo qualità. Per ridurre il loro costo, stiamo lavorando per mettere a disposizione degli snapshot giornalieri completi (ovvero in tutte le lingue) del ramo di sviluppo, al fine di consentire un test continuo dei miglioramenti al codice. Questo lavoro è già parzialmente disponibile e può essere visionato/scaricato qui.

Allo stesso modo, abbiamo in programma di incrementare gli automatismi del processo di compilazione, in modo da consentire un flusso di rilascio che abbia un impatto molto più leggero e continuando a ridurre l'occupazione di memoria dei binari, così da consentire un trasferimento più rapido dei pacchetti compilati equivalenti al prodotto finale.

Rilasci EOL (Fine vita)

Una versione normalmente ha un ciclo di vita di circa nove mesi. Consideriamo che una versione ha raggiunto il suo Fine vita (EOL) un mese dopo l'ultimo rilascio minore pianificato.

Se desiderate avere un supporto più lungo per una determinata versione, vi invitiamo ad affidarvi ad uno sviluppatore certificato L3 in grado di fornirvi questo servizio.

In considerazione della quantità di dati presenti, alcune versione sono state riepilogate nell'Archivio del piano di rilascio.