Piano di rilascio
TDF LibreOffice Document Liberation Project Blog comunitari Weblate Nextcloud Redmine Ask LibreOffice Donazione
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, con rapidità, in modo incrementale, con dei rilasci per la correzione di bug, basati sulla precedente versione stabile. Quindi se avete bisogno di una versione di qualità elevata, potrebbe essere sensato posticipare l'aggiornamento al primo, o anche al secondo, rilascio minore.
- 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.
- la sincronizzazione delle scadenze dei rilasci con quelle del più ampio ecosistema del Software Libero presenta grandi benefici, mettendo a disposizione degli utenti le nuove funzionalità il prima possibile, con un minimo intervallo nel ciclo di distribuzione. Come risultato, puntiamo ad avere dei rilasci semestrali in Febbraio ed Agosto.
- Sono disponibili due versioni: l'ultima versione per gli amanti della tecnologia, "pionieri" ed utenti esperti e la versione precedente - con qualche funzionalità in meno ma testata più a lungo - per le installazioni in ambito aziendale e gli utenti più prudenti.
- di conseguenza agli utenti avranno una nuova versione principale ogni sei mesi, con un'ampia gamma di nuove funzionalità, correzioni e miglioramenti. Riceveranno inoltre diverse 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.3/X.Y.4.
Si precisa che le date indicate in questo programma potrebbero cambiare 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 presenti un problema catastrofico. Problemi di questo tipo potrebbero ritardare il rilascio finale di una settimana o più. Tale decisione dovrebbe essere adottata da una riunione dell'Engineering Steering Committee.
Il grafico semplificato sottostante visualizza tre versioni posizionate su di una timeline di 24 mesi.
Versione 24.2
Versione | Congelamento | Pubblicazione |
---|---|---|
24.2.0 (congelamento: settimana 02) | Settimana 47 , nov 20, 2023 - nov 26, 2023 | Settimana 05 , gen 29, 2024 - feb 4, 2024 |
24.2.1 | Settimana 06 , feb 5, 2024 - feb 11, 2024 | Settimana 09 , feb 26, 2024 - mar 3, 2024 |
24.2.2 | Settimana 10 , mar 4, 2024 - mar 10, 2024 | Settimana 13 , mar 25, 2024 - mar 31, 2024 |
24.2.3 | Settimana 15 , apr 8, 2024 - apr 14, 2024 | Settimana 18 , apr 29, 2024 - mag 5, 2024 |
24.2.4 | Settimana 20 , mag 13, 2024 - mag 19, 2024 | Settimana 23 , giu 3, 2024 - giu 9, 2024 |
24.2.5 | Settimana 26 , giu 24, 2024 - giu 30, 2024 | Settimana 29 , lug 15, 2024 - lug 21, 2024 |
24.2.6 | Settimana 33 , ago 12, 2024 - ago 18, 2024 | Settimana 36 , set 2, 2024 - set 8, 2024 |
24.2.7 | Settimana 41 , ott 7, 2024 - ott 13, 2024 | Settimana 44 , ott 28, 2024 - nov 3, 2024 |
Fine vita | 30 novembre 2024 |
Consultate anche il programma dettagliato e le note di rilascio.
versione 7.6
Versione | Congelamento | Pubblicazione |
---|---|---|
7.6.0 (congelamento: settimana 30) | Settimana 19 , mag 8, 2023 - mag 14, 2023 | Settimana 34 , ago 21, 2023 - ago 27, 2023 |
7.6.1 | Settimana 34 , ago 21, 2023 - ago 27, 2023 | Settimana 37 , set 11, 2023 - set 17, 2023 |
7.6.2 | Settimana 38 , set 18, 2023 - set 24, 2023 | Settimana 39 , set 25, 2023 - ott 1, 2023 |
7.6.3 | Settimana 44 , ott 30, 2023 - nov 5, 2023 | Settimana 47 , nov 20, 2023 - nov 26, 2023 |
7.6.4 | Settimana 50 , dic 11, 2023 - dic 17, 2023 | Settimana 53 , gen 1, 2024 - gen 7, 2024 |
7.6.5 | Settimana 05 , gen 29, 2024 - feb 4, 2024 | Settimana 08 , feb 19, 2024 - feb 25, 2024 |
7.6.6 | Settimana 10 , mar 4, 2024 - mar 10, 2024 | Settimana 13 , mar 25, 2024 - mar 31, 2024 |
7.6.7 | Settimana 16 , apr 15, 2024 - apr 21, 2024 | Settimana 19 , mag 6, 2024 - mag 12, 2024 |
Fine vita | 12 giugno 2024 |
Consultate anche il programma dettagliato e le note di rilascio.
versione 7.5
Versione | Congelamento | Pubblicazione |
---|---|---|
7.5.0 (congelamento: settimana 02) | Settimana 47 , nov 21, 2022 - nov 27, 2022 | Settimana 05 , gen 30, 2023 - feb 5, 2023 |
7.5.1 | Settimana 06 , feb 6, 2023 - feb 12, 2023 | Settimana 09 , feb 27, 2023 - mar 5, 2023 |
7.5.2 | Settimana 10 , mar 6, 2023 - mar 12, 2023 | Settimana 13 , mar 27, 2023 - apr 2, 2023 |
7.5.3 | Settimana 15 , apr 10, 2023 - apr 16, 2023 | Settimana 18 , mag 1, 2023 - mag 7, 2023 |
7.5.4 | Settimana 20 , mag 15, 2023 - mag 21, 2023 | Settimana 23 , giu 5, 2023 - giu 11, 2023 |
7.5.5 | Settimana 26 , giu 26, 2023 - lug 2, 2023 | Settimana 29 , lug 17, 2023 - lug 23, 2023 |
7.5.6 | Settimana 33 , ago 14, 2023 - ago 20, 2023 | Settimana 36 , set 4, 2023 - set 10, 2023 |
7.5.7 | Settimana 38 , set 18, 2023 - set 24, 2023 | Settimana 39 , set 25, 2023 - ott 1, 2023 |
7.5.8 | Settimana 41 , ott 9, 2023 - ott 15, 2023 | Settimana 44 , ott 30, 2023 - nov 5, 2023 |
Fine vita | 30 novembre 2023 |
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:
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.
In pratica dovreste tenere d'occhio il tagging della prima release candidate. Un modo per scoprire se RC1 è stato taggato è visitare la visualizzazione tag del repository principale di LibreOffice in Gerrit e inserire nel campo filtro: libreoffice-X.Y.Z
. Se i risultati non contengono alcuna voce per libreoffice-X.Y.Z.1
, RC1 non è stato ancora contrassegnato e le modifiche alla stringa possono ancora essere confermate.
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.