ReleasePlan/it

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ù.

Il grafico semplificato sottostante visualizza tre versioni posizionate su di una timeline di 24 mesi.

Future Fresh Still

versione 7.4
Consultate anche il programma dettagliato e le note di rilascio.

Versione 7.3
Consultate anche il programma dettagliato e le note di rilascio.

Versione 7.2
Consultate anche il programma dettagliato e le note di rilascio.

Versione 7.1
Consultate anche il programma dettagliato e le note di rilascio.

versione 7.0
Consultate anche il programma dettagliato e le note di rilascio.

versione 6.4
Consultate anche il programma dettagliato e le note di rilascio.

versione 6.3
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:

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.