Anche i meno esperti sapranno che quei numerini che stanno alla fine del nome di un software servono ad indicarne la versione. Prendiamo ad esempio Android 7.1.2. Come mai 7.1.2 e non semplicemente 8? Oppure, perché 7.1.2 e non semplicemente 7.2? Insomma, a che diavolo servono tutti sti numeri e come funziona?
Ogni numero svolge un ruolo ben preciso.
Il primo numero indica una major release, ovvero una versione importante del software, in cui la struttura generale può cambiare radicalmente. Ad esempio, Android 6 e Android 7 sono due sistemi operativi diversi e alcune app possono girare sulla 7 ma non sulla 6. Insomma, si tratta di software potenzialmente diversi e che possono non avere alcuna compatibilità. Passare ad una nuova major release non sempre è possibile (nel caso di Android dipende dall’hardware) e non sempre semplice.
Il secondo numero indica una minor release, ovvero una versione che introduce nuove funzionalità e corregge bug importanti (cioè delle falle). Ad esempio, Andorid 7.1.0 ha introdotto le App Shortcut. Passare ad una nuova minor release è generalmente possibile e facile da fare.
Il terzo numero indica una revision, ovvero una versione in cui generalmente vengono corretti piccoli bug. Ad esempio, in Android 7.1.1 sono state introdotte nuove emoji e nella 7.1.2 sono stati corretti piccoli malfunzionamenti. Cambiare versione di revision è semplice e spesso l’aggiornamento è automatico.
Se siete curiosi, vi linko i dettagli delle release di Andorid 7.
Vi ho dato un’idea di come funzionano i rilasci, ma in realtà dipende tutto dalle software house e dalla loro filosofia. Ad esempio c’è chi fa una scrematura delle build (numero di compilazioni) inserendo un quarto numerino. Ultimamente si sta diffondendo una nuova tendenza, che vede utilizzare nel numero di versione l’anno di rilascio, un po’ come ha fatto PES, passando da PES 6 a PES 2008 :p
Alpha, Beta, RC, LTS?
Durante il processo di sviluppo, potrebbe essere utile identificare una versione in particolare, aggiungendo delle “etichette”, di cui avrete già sentito parlare. Sono le fasi attraverso cui un software deve passare:
Versione alpha: è una versione non completa delle funzionalità designate e non è testata, per cui è facile che sia piena di bug. Essendo ancora rozza, chiaramente non è una versione adatta ad essere lanciata sul mercato.
Versione beta: è una versione più avanzata dell’alpha, perché implementa tutte le funzionalità ed è adatta ad essere testata, ma non è ancora ritenuta stabile, per cui nemmeno questa può essere lanciata. In questa fase sono fondamentali i test, che devono essere eseguiti in tutti gli ambienti possibili (sia hardware che software).
Release Candidate (RC): come dice il nome, è una versione “candidata” a diventare stabile e poter essere usata in produzione. Generalmente possono esserci più RC, che non differiscono per le funzionalità, ma solo per la correzione di bug. Insomma è il passo che precede il lancio.
Long Term Support (LTS): è una versione stabile a lungo supporto. Supportare una versione vuol dire offrire aggiornamenti per fixare bug o implementare piccole feature. La durata del supporto per le versioni non LTS è di alcuni mesi, mentre per le versioni LTS è di alcuni anni.
Mi preme evidenziare il fatto che queste fasi rientrano nel ciclo di vita del software e costituiscono un argomento fondamentale nell’ambito dell’Ingegneria del Software, per cui sono nozioni che possono essere esplorate in modo mooolto più approfondito (esistono libri e libri a riguardo), ma comunque quanto scritto può essere utile per farsi un’idea generale.
