Piano di rilascio

    From The Document Foundation Wiki
    This page is a translated version of the page ReleasePlan and the translation is 100% complete.

    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.

    Future
    Fresh
    Still

    Versione 24.2

    Date di massima per il rilascio delle versioni iniziale e di bugfix
    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

    Date di massima per il rilascio delle versioni iniziale e di bugfix
    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

    Date di massima per il rilascio delle versioni iniziale e di bugfix
    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:

    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.

    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.