 Dicembre del 2009, New York City.
Quando la neonata Leadership Team di produzione (PLT) di Joomla si riunì a New York City nel dicembre 2009, dovette affrontare una sfida.
Anche se Joomla! versione 1.5 aveva ormai raggiunto la sua popolarità, erano trascorsi già due anni dal suo rilascio.
Il codice per la versione 1.6 conteneva molte caratteristiche incomplete e parti non testate e nessuno poteva dire con certezza quanto tempo occorreva affinchè la versione 1.6 sarebbe stata pronta per il rilascio ufficiale. Inutile dire che non si credeva che la lentezza dei rilasci e l'incertezza del futuro fosse vantaggioso sia per il progetto che per la community di utenti.
Così si decise di tracciare una rotta precisa per porre rimedio alla situazione attuale e cercare di impedire che un problema simile si ripresentasse
in futuro. Furono prese due decisioni chiave a quel meeting: adottare un "ramo di sviluppo" o (branch) stabile e rilasciare release a distanza di tempi stabiliti.
Ramo di sviluppo Stabile
Nel linguaggio di CM (Control Management) e quindi di controllo di versionamento del codice sorgente di un software, quando si parla di trunk (albero) principale ci si riferisce al codice sorgente utilizzato per il rilascio di versioni ufficiali pianificate. A loro volta, gli sviluppatori possono creare nuovi rami (branch) da quello principale, per lavorare su modifiche o cambiamenti sostanziali del programma, come ad esempio l'aggiunta di nuove funzionalità.
Questo in pratica significa che il gruppo di sviluppatori che lavorano su questo nuovo 'ramo' possono apportare tutte le modifiche che reputano opportune senza modificare effettivamente il ramo principale di sviluppo o andare in conflitto con altre modifiche apportate da atri sviluppatori in altrettanti rami.
Una volta che le nuove funzionalità sono state terminate e opportunamente testate, potranno essere 'mergiate' nel ramo principale; questo significa
che diventeranno parte del ramo da cui sono nate in modo che saranno disponibili con il prossimo rilascio ufficiale.
L'idea di un branch stabile è semplice: un ramo (si pensi ad una nuova funzione) non viene unito nuovamente nel ramo principale se non è completo
,collaudato e pronto per il rilascio.
Questo sembra semplice ed ovvio, ma nella pratica può essere difficile. Ad esempio, una caratteristica potrebbe essere al "99%" pronta "ad eccezione di alcune piccole cose che possono essere risolte in una successiva release". In queste situazioni si può essere tentati a unire comunque i due rami , soprattutto se la funzione è molto richiesta e il termine di rilascio è vicino. Non è piacevole ricevere la notizia che una feature a cui si è lavorato per lunghe ore è stato fatto il cut-off o non è stata accettata. Quali sono i vantaggi di un ramo principale stabile?
Uno è che le diverse squadre di sviluppatori possono lavorare in modo indipendente su rami diversi con una ragionevole certezza che nessuna delle parti di codice mergiato corromperà il sorgente del ramo principale. Questo riduce notevolmente la probabilità che i cambiamenti creati da un team causerà problemi per altri team.
Un altro importante vantaggio è il seguente: se si dispone di un ramo principale stabile, è possibile rilasciare una versione in qualsiasi momento, semplicemente rilasciando il suo ultimo ramo principale disponibile. Questo rende possibile release basati su una linea temporale ben definita.
Ciclo di release basate su time-line
Il fisico danese Niels Bohr una volta disse: "La previsione è molto difficile, soprattutto per il futuro." Ciò vale sicuramente per prevedere quando una caratteristica del software sarà pronta. E' doppiamente vero in un progetto di sviluppo di tipo "volunteer-driven" come Joomla. In una Società, normalmente si conosce quante ore/persona si può dedicare ad un compito. Con Joomla, non sappiamo chi potrebbe lavorare su un task assegnatogli o quante ore o giorni potrebbe quella stessa persona avere a disposizione, per non parlare di quando potrebbero finire.
Quindi è impossibile prevedere con precisione quando le nuove caratteristiche saranno pronte per il rilascio. D'altra parte, ci sono grandi benefici per la community ad avere un ciclo prevedibile di rilascio.
La soluzione scelta dal PLT è stata quella di rilasciare un calendario ben preciso con pianificazioni stabilite, ma con una importante condizione:
non vi è nessuna garanzia di quando una determinata features potrebbe essere rilasciata.
Ad esempio, possiamo prevedere con una certa sicurezza che la versione 3.0 sarà rilasciata nel mese di settembre 2012. Ma non sappiamo quali
nuove funzionalità saranno introdotte con la versione 3.0 fino a quando non sarà terminata e quindi non sono stati aggiunti al codice di base.
Release STS e LTS
Con queste premesse in mente, diamo un'occhiata alle specifiche del corrente ciclo di rilascio Joomla. In quello stesso incontro avvenuto nel 2009, il PLT si prefisse un obiettivo ambizioso - quello di rilasciare una nuova versione di Joomla ogni sei mesi.
Perché questi frequenti rilasci? Una considerazione importante è quello di motivare gli sviluppatori. I volontari che contribuiscono allo sviluppo del progetto vogliono vedere il loro codice e le loro funzioni implementate utilizzate. Se il tempo tra una release è troppo lungo, si perde questa fattore motivante. Rilasciando più frequentemente si rende anche più facile stare al passo con le versioni di software su cui Joomla si basa - come PHP, MySQL, e TinyMCE. Tutti questi programmi sono in costante sviluppo e cambiamento, per cui Joomla! deve essere in grado di tenere il passo.
Per raggiungere questo ambizioso obiettivo, c'èra bisogno di fare in modo che gli aggiornamenti fossero semplici. Ad esempio, la migrazione dalla versione 1.5 alla versione 1.6 è una sfida. Ciò è in gran parte perché c'erano così tanti cambiamenti (tre anni di sviluppo!) tra queste versioni. D'altra parte, gli aggiornamenti dalla versione 1.6 a 1.7 e 1.7 a 2.5 sono stati (si spera!) relativamente semplici, e stiamo lavorando per renderli sempre più semplici e immediati.
Ad esempio, la versione 2.5 ha introdotto la notifica automatica degli aggiornamenti e siamo in procinto di introdurre un motore degli aggiornamenti più
performante che avrà una maggiore affidabilità sugli host più lenti.
Rilasciando nuove versioni con più frequenza significa anche che occorre stare attenti alla compatibilità con quelle precedenti. Ad esempio, le estensioni che funzionano con la versione 1.6 dovrebbero funzionare anche con 1.7 e 2.5.
Anche con una modalità degli aggiornamenti migliorata e una buona compatibilità, il Team PLT ha riconosciuto che un periodo di sei mesi come ciclo di rilascio non è un buon metodo per molti siti. Ecco perché abbiamo aggiunto anche l'idea di un ciclo di rilasci a lungo termine (LTS). Ad esempio, le versioni 1.6 e 1.7 facevano parte dello short-term (STS) cioè lo standard denominato di breve periodo, mentre la 2.5 è una release LTS. Questo significa che la versione 2.5 sarà supportato almeno fino alla prossima release LTS (versione 3.5) - attualmente prevista per settembre 2013.
Così l'idea di STS e rilasci LTS è molto semplice. Se volete caratteristiche d'avanguardia (quindi avere a disposizione features di particolare interesse senza badare ad eventuali problemi di instabilità del sistema), si dovrebbe andare con la release STS - per esempio, versione 3.0 disponibile nel mese di settembre 2012, 3.1 nel marzo 2013, e 3.5 nel mese di settembre 2013.
Se si desidera la stabilità e si può vivere con il set di funzionalità della versioni 2.5, è consigliabile restare con questa versione fino all'uscita della versione 3.5, quindi aggiornare alla 3.5. Stessa cosa con la versione 4.
Seguire il percorso di release 4.0 / 4.1 / 4.5 per ottenere l'ultima, più grande, o attendere la 4.5 per ridurre il numero di aggiornamenti che si dovrà altrimenti fare.
La scelta è interamente lasciata alle vostre esigenze. L'unica condizione è questa: se si va con una versione STS (ad esempio 3.0 o 3.1), è necessario capire che queste hanno una vita breve e che occorrerà un impegno ulteriore e maggiore attenzione per aggiornare ogni sei mesi fino ad arrivare alla prossima release LTS (per esempio, 3.5).
A quel punto, si può decidere se rimanere sul sentiero STS (e andare per 4.0 / 4.1 / 4.5) o passare al percorso LTS (e aspettare per la versione 4.5).
Spero che questo articolo possa aiutarvi a fare chiarezza e capire meglio l'attuale ciclo di rilasci di Joomla!. Qui di seguito riporto alcune FAQ.
FAQ's
Perché saltiamo dalla versione 1.7-2.5?
In un incontro nel mese di luglio 2011, il team PLT decise che le cose sarebbero state più semplici se tutte le versioni LTS fossero state rese X.5, quindi release (1.5, 2.5, 3.5, e così via). Per arrivarci, si avrebbe potuto (a) nel gennaio 2012 chiamare come versione 1.8, come previsto e iniziare la numerazione X.5 con la versione 2, o (b) si sarebbe potuti passare dalla 1.7 alla 2.5 come prossima release LTS . E' stato deciso di mettere ai voti la questione alla comunità e la comunità ha scelto l'opzione (b). Quindi la versione del Gennaio 2012 è stata chiamata 2.5 ed è l'attuale versione LTS.
Perché la versione 3.0 è prevista per settembre 2012 invece di luglio 2012?
Mentre il ciclo di rilasci sta attraversando il processo della 2.5, è stato suggerito che dicembre è un mese particolarmente difficile per molte persone a trovare del tempo extra necessario prima di assorbire un nuovo rilascio. Dopo molte discussioni, è stato deciso di spostare i mesi di rilascio da luglio / gennaio a marzo / settembre. Si continuerà quindi a rilasciare su un programma di sei mesi, ma si farà uno sforzo particolare per apportare una regolazione ai mesi di rilascio. Così la versione 3.0 è prevista per settembre 2012, la 3.1 per marzo 2013, e la 3.5 per settembre 2013.
Quando la versione 1.5 raggiungere la fine del suo ciclo di vita?
Il piano originale era che la versione 1.5 avrebbe concluso il suo ciclo di vita nel mese di aprile 2012. Tuttavia, un considerevole numero di persone ha espresso il desiderio di vedere questo periodo esteso. In pratica, la versione 1.5 non ha richiesto molti aggiornamenti nel corso dell'anno passato, per cui estendere il periodo LTS non avrebbe dovuto richiedere molto tempo o un dispendio notevole di risorse di progetto.
Nessun annuncio ufficiale è stato fatto dal PLT, ma il supporto per la versione 1.5 sarà portata avanti probabilmente almeno fino a settembre 2012.
I cambiamenti dalla 2.5 alla 3.0 saranno più consistenti rispetto alle modifiche alle versioni dalla 1.7 a 2.5?
In teoria, il passaggio dalla versione 2.5 alla 3.0 potrebbero essere più grandi della variazione 1.7 alla 2.5. Poiché tutti gli utenti che utilizzano la versione 1.7 avrebbero dovuto aggiornarsi alla versione 2.5 subito, l'aggiornamento doveva essere il più trasparente e semplice possibile, e con il più alto grado di compatibilità possibile. Con l'aggiornamento dalla 2.5 alla 3.0, la situazione è differente. Gli utenti con la versione 2.5 hanno la possibilità di rimanere con questa versione per il periodo di supporto esteso (ed eventualmente aggiornare alla versione 3.5) o aggiornare alla versione 3.0. Dato che l'aggiornamento 3.0 è opzionale, non vi è più margine di manovra per apportare modifiche tra 2.5 e 3.0 per cui possono richiedere una migrazione o alcuni cambiamenti nelle estensioni.
In entrambi i casi, vogliamo rendere l'aggiornamento più semplice possibile e di fornire il più alto grado di compatibilità possibile. Da 3.0 alla 3.1 e dalla 3.1 alla 3.5, lavoreremo ancora per rendere gli aggiornamenti assolutamente senza interruzioni. Tuttavia, occorre tenere presente che non possiamo prevedere esattamente quali funzioni saranno pronte in tempo per la versione 3.0, in modo da sapere con certezza quanto grandi siano i cambiamenti fino a quando non ci troviamo più vicini alla data del rilascio.
In futuro, può cambiare l'attuale ciclo di rilascio?
L'attuale ciclo di rilascio non è "scritto nella pietra" e potrebbe essere modificato in futuro, sulla base dell'esperienza e dei feedback provenienti della comunità.
Una volta che la versione 3.0 verrà rilasciata, avremo passato un intero ciclo di release LTS e STS. A quel punto, sarà utile questo tempo per valutare come ha funzionato nella pratica e apportare le eventuali modifiche.
ATTENZIONE: Le versioni di Joomla 1.6 e 1.7 hanno attualmente terminato il loro periodo di supporto ufficiale. Non sono quindi più previsti aggiornamenti per questi due cicli di sviluppo ed essendo presenti in entrambe alcuni BUG di sicurezza molto gravi si consiglia vivamente di abbandonare queste versioni aggiornandole alla 2.5
Nel wiki di Joomla.it è presente una utile guida all'aggiornamento da 1.6 a 1.7 e la guida per aggiornare da 1.7 a 2.5
Traduzione a cura di Crismer dell'articolo: Joomla! Versions and Updates Explained
 Commenta questo articolo sul forum
 Oppure commenta e condividi questo articolo sulla nuova pagina ufficiale di Joomla.it su Google+
Vedi anche:
Articoli più recenti:
|
