Piano di rilascio

From The Document Foundation Wiki
Jump to: navigation, search

I processi di rilascio a tempo prestabilito hanno dimostrato di produrre il Software Libero di miglior qualità. Un rilascio a tempo prestabilito non si ferma ad aspettare né funzionalità né correzioni di bug - ma si basa (per quanto possibile) su una data. Questo rafforza la disciplina di introdurre correzioni, dà una prevedibilità, e permette dei rilasci più regolari. E' anche vero che rilasciamo necessariamente più presto, e con rapidità, dei rilasci incrementali correttivi di bug basati sulla precedente versione stabile, quindi se avete bisogno di una versione di più alta qualità, può essere utile attendere fino al primo o secondo rilascio minore.

Sincronizzare il nostro piano di rilascio con il più ampio ecosistema del Software Libero ha anche grandi vantaggi, offrendo le nostre nuove funzionalità il più rapidamente possibile agli utenti - con un minimo di attesa nel ciclo di distribuzione. Di conseguenza, puntiamo a rilasci semestrali, spingendoli nel tempo ad allinearsi bene con la norma di Marzo/Settembre.

Come risultato, gli utenti ottengono ogni 6 mesi una nuova versione principale con una vasta gamma di funzionalità, correzioni e miglioramenti. Inoltre, ottengono vari micro rilasci correttivi di bug. La prima versione X.Y.0 è destinata agli utenti occasionali, a chi necessita di stabilità si consiglia di attendere una versione di mantenimento X.Y.Z rilasciata più avanti.

Si noti che le date indicate nel calendario potrebbe slittare in caso di gravi problemi tecnici o di altra natura. Se la Release Candidate finale non rispetta i criteri di rilascio potrebbe essere necessaria un'altra RC: in tal caso la versione finale può slittare di una settimana o anche più.

Release 5.1

Leggi il piano di rilascio dettagliato e le note di rilascio.

Release 5.0

Leggi il piano di rilascio dettagliato e le note di rilascio.

Release 4.4

Leggi il piano di rilascio dettagliato e le note di rilascio.

Date

Il rilascio ha date prestabilite, ma la tabella di marcia mostra settimane del calendario, invece di date precise. E' perché siamo sempre un po' flessibili: un rilascio può essere ritardato di qualche giorno a causa di bug bloccanti, problemi di build e altre questioni tecniche.

Il piano di rilascio è costituito da varie Beta e Release Candidate e sono necessarie diverse azioni per ogni build. Il flusso di lavoro ideale assomiglia a:

  • Lunedi - termine ultimo commit; promemoria a sviluppatori e traduttori prima che accada
  • Martedì - il tag viene creato su un commit che passa i test e viene annunciato sulle mailing list di sviluppatori e addetti al controllo qualità
  • Mercoledì – le builds sono caricate sul sito delle pre-release e annunciate sulle mailing list di sviluppatori e addetti al controllo qualità
  • Giovedi – le builds sono caricate sui mirror
  • Venerdì – le builds sono disponibili sul sito ufficiale delle pre-release e annunciate attraverso vari canali, ad esempio le mailing list o Twitter

La versione finale di solito è annunciata il Mercoledì, pochi giorni dopo il rilascio della release candidate.

Si noti che siamo molto severi sui commit applicati alla Release Candidate finale, in modo che non servano test di regressione completi. Essa è usata come build finale quando passa i test necessari e viene semplicemente rinominata sui mirror.

Tabella di marcia

La tabella di marcia si basa sulle seguenti regole:

  • fare un rilascio principale ogni sei mesi e sincronizzarlo con le principali distribuzioni Linux: si tratta sempre di una vasta gamma di funzionalità, correzioni e miglioramenti
  • fare un rilascio di puro bugfix ogni mese dopo la release principale, fino a quando non è abbastanza buono anche per le persone più caute; farlo meno frequentemente in seguito
  • fare rilasci di puro bugfix, inclusi aggiornamenti di sicurezza, fino a quando la prossima release è pronta per le persone più caute
  • non fare due build nella stessa settimana

Il risultato è il seguente modello:

Rilasci ad incastro
evento estate inverno
x.y feature freeze Giu(i) Dic(i)
x.y.0 prima release Ago(i) Feb(i)
x.y.1 bugfix release Set(i) Mar(i)
x.y.2 bugfix release Ott(i) Apr(i)
x.y.3 bugfix release Nov(i) Mag(i)
x.y.4 bugfix release Dic(i) Giu(i)
x.y.5 bugfix release Feb(m) Ago(m)
x.y.6 bugfix release Apr(m) Ott(m)

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

Schema di rilascio

Facciamo svariate builds per ogni rilascio. Si usa il seguente schema di versione:

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

Sembra essere il miglior compromesso con i seguenti vantaggi:

  • facile da capire per gli utenti comuni, i tag alpha e beta sono noti da altri progetti, quindi è ciò che ci si aspetta
  • ordine alfabetico corretto in RPM e Bugzilla
  • "facile" da processare (le stringe alpha/beta sono separate da punti)

C'è stata una lunga discussione sulla mailing list riguardo a questo schema.

Accelerare il ciclo di rilascio

Questa velocizzazione del ciclo di rilascio comporta un considerevole sforzo ingegneristico e di controllo qualità. Per ridurne il peso, stiamo lavorando per offrire snapshots giornalieri completi (ovvero in tutte le lingue) del ramo di sviluppo per consentire un testing continuo dei miglioramenti al codice. Questo in parte è già disponibile e può essere visto/scaricato qui.

Allo stesso modo, pianifichiamo di rendere più automatico il processo di build per consentire un flusso di rilascio molto meno pesante, continuando a ridurre l'impronta di memoria dei nostri binari per avere un trasferimento più rapido delle builds equivalenti al prodotto finale.

Rilasci EOL (End of Life)

Una release normalmente ha un ciclo di vita di circa nove mesi. Consideriamo che una release ha raggiunto il suo End of Life (fine vita) un mese dopo l'ultimo rilascio minore pianificato.

Se desideri un supporto più lungo per una release, sei incoraggiato ad ingaggiare uno sviluppatore certificato L3 che potrebbe fornirti il servizio.

Release 4.3

Leggi il piano di rilascio dettagliato e le note di rilascio.

Release 4.2

Leggi il piano di rilascio dettagliato e le note di rilascio.

Release 4.1

Leggi il piano di rilascio dettagliato e le note di rilascio.

Release 4.0

Leggi il piano di rilascio dettagliato e le note di rilascio.

Release 3.6

Leggi il piano di rilascio dettagliato e le note di rilascio in Inglese.

Release 3.5

Leggi il piano di rilascio dettagliato e le note di rilascio in Inglese.

Release 3.4

Leggi il piano di rilascio dettagliato e le note di rilascio in Inglese.

Release 3.3

Leggi il piano di rilascio e le note di rilascio in Inglese.