improved translation
← Older revision
Revision as of 2013-08-20T08:07:45
Line 6:
Line 6:
== Riepilogo ==
== Riepilogo ==
[[File:LibOReleaseLifecycle.png|thumb|350px|right|Ciclo di rilascio di LibreOffice ]]
[[File:LibOReleaseLifecycle.png|thumb|350px|right|Ciclo di rilascio di LibreOffice ]]
−
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
un
bisogno di una versione di più alta qualità, può essere utile attendere fino al primo o secondo rilascio minore.
+
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.
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.
Line 42:
Line 42:
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 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
,
sono necessarie diverse azioni per ogni build. Il '''flusso di lavoro ideale''' assomiglia a:
+
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
* '''Lunedi''' - termine ultimo commit; promemoria a sviluppatori e traduttori prima che accada
−
* '''Martedì''' - il tag viene creato su un commit che i test e viene annunciato sulle mailing list di sviluppatori e addetti al controllo qualità
+
* '''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 [http://dev-builds.libreoffice.org/pre-releases/ sito delle pre-release] e annunciate
generazioni sono caricato sul sito di pre-rilascio anticipato, sono annunciati
sulle mailing list di sviluppatori e addetti al controllo qualità
+
* '''Mercoledì''' – le builds sono caricate sul [http://dev-builds.libreoffice.org/pre-releases/ sito delle pre-release] e annunciate sulle mailing list di sviluppatori e addetti al controllo qualità
* '''Giovedi''' – le builds sono caricate sui mirror
* '''Giovedi''' – le builds sono caricate sui mirror
* '''Venerdì''' – le builds sono disponibili sul [http://www.libreoffice.org/download/pre-releases/ sito ufficiale delle pre-release] e annunciate attraverso vari canali, ad esempio le mailing list o Twitter
* '''Venerdì''' – le builds sono disponibili sul [http://www.libreoffice.org/download/pre-releases/ sito ufficiale delle pre-release] e annunciate attraverso vari canali, ad esempio le mailing list o Twitter
Line 58:
Line 58:
La tabella di marcia si basa sulle seguenti regole:
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 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 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ù
prudenti
+
* 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
* non fare due build nella stessa settimana
Line 110:
Line 110:
Sembra essere il miglior compromesso con i seguenti vantaggi:
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ò ci si aspetta
+
* 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
+
* ordine alfabetico corretto in RPM e
Bugzilla
−
* "
easy
"
to
processare (le stringe alpha/beta sono separate da punti)
+
* "
facile
"
da
processare (le stringe alpha/beta sono separate da punti)
C'è stata una [http://lists.freedesktop.org/archives/libreoffice/2012-June/033211.html lunga discussione] sulla mailing list riguardo a questo schema.
C'è stata una [http://lists.freedesktop.org/archives/libreoffice/2012-June/033211.html lunga discussione] sulla mailing list riguardo a questo schema.