I software realizzati vengono rilasciati sotto forma di versioni e release, ciascuna identificata da un numero intero progressivo con in aggiunta uno o più numeri decimali. L’ordine di rilascio segue un andamento progressivo della numerazione dove versione e release successive rappresentano evoluzioni delle precedenti con miglioramenti in termini di nuove caratteristiche e funzionalità aggiunte e/o errori corretti.
Di seguito indico il metodo di versioning adottato nella mia attività. Tale metodo può essere utile a molte realtà di sviluppo software, sia per piccoli che per grandi progetti.
In questa prima parte spiego come utilizzare l’assembly version ed il file assembly version per indicare la versione e la data di compilazione del programma, più altre informazioni utili.
Nell’articolo successivo indicherò invece come rendere automatico l’inserimento di questi indici all’interno del programma ad ogni compilazione.
Struttura dell’indice
La struttura dell’indice di versione è la seguente:
Assembly version
mayor.minor.release+revision.source
(Es.: 1.0.12.17)
Assembly file version
mayor.minor.builddate.buildtime
(Es.: 1.0.4519.781)
Indice di versione Maggiore (Major)
Con indice di versione maggiore si indica lo stato di revisione massimo di un software e viene aggiornato ogni volta che si effettua una modifica importante al software. Tale modifica può essere ad esempio la riscrittura di tutto o parte del software, implementazione di nuove librerie grafiche.
L’indice viene incrementato a discrezione del responsabile del progetto e può anche non essere consecutivo con l’indice precedente.
Indice di versione Minore (Minor)
Con indice di versione minore si indica lo stato di revisione minimo di un software e viene aggiornato ogni volta che si effettua un’aggiunta o modifica al software che non sia la semplice correzione di errori. Tale modifica può essere ad esempio l’aggiunta di una nuova procedura, l’aggiunta o la rimozione di funzioni con accesso condiviso.
L’indice viene incrementato di una unità e deve essere sempre consecutivo con l’indice precedente.
Ad ogni modifica dell’indice di versione maggiore, si riparte dall’indice 0.
Indice di release (Release)
Con indice di release si indica lo stato di sviluppo del software. Ogni stato può avere più revisioni, che vengono indicate da un numero progressivo aggiunto all’indice di release: Alpha, Beta, Candidate Release, General Availability e Maintenance Release.
Ad ogni modifica dell’indice di versione minore, si riparte dall’indice di release Alpha.
Per progetti di piccole dimensioni o con pochi sviluppatori, tutto il ciclo delle release può risultare troppo complesso ed oneroso da gestire, per questo motivo ho previsto uno stato “Not Applicable”, da utilizzare nei progetti in cui non si vuole gestire per intero tutto il ciclo.
Not Applicable (na)
La release “Not Applicable” viene utilizzata nei progetti in cui non si ritiene necessario gestire tutte le varie fasi delle release. In questo caso l’indice di release sarà sempre lo stesso “na“.
Alpha (a)
La release “Alpha”, individua un software che è in fase di sviluppo, le cui funzionalità non sono ancora state completamente implementate e che presenta sicuramente una lunga serie di bug che dovranno essere risolti.
Solitamente durante lo sviluppo di un software vengono realizzate diverse versioni Alpha, in alcuni casi (soprattutto nel caso di software open-source) pubbliche, per introdurre nuove caratteristiche del software delle quali è necessario controllare il funzionamento a fondo. Le versioni Alpha sono quindi da considerare incomplete e mancanti di alcune funzionalità e, spesso, instabili e perciò non adatte all’utente finale.
La successiva fase di sviluppo è la Beta, uno step in cui il software ha acquisito quasi tutte le funzionalità finali e necessita delle rifiniture.
Beta (b)
La release “Beta” si riferisce ad una fase di prova e collaudo del software non ancora pubblicato, con lo scopo di trovare eventuali errori (bug). Questa operazione può essere svolta da professionisti specializzati, oppure, molto spesso, da semplici amatori, chiamati beta tester. La loro importanza è legata, oltre al test dei sistemi operativi, anche ai programmi minori poiché tendono a comportarsi diversamente in base all’hardware su cui girano, per cui conviene avere la possibilità di provarli su più hardware differenti.
La distribuzione della versione beta del software può essere ristretta ad un piccolo numero di persone oppure accessibile a tutti, a seconda dei casi.
Gli utenti ricevono il software senza alcuna garanzia (anzi, con la garanzia che ci sarà qualcosa che non va) e segnalano al produttore i difetti incontrati. Ciò facilita molto il lavoro del produttore, perché molti bug sono difficili da scoprire e si rivelano solo in casi particolari, ed è più facile che essi vengano a galla quando le persone che provano il software sono migliaia.
Va sottolineato che generalmente con “versione beta” si intende un software potenzialmente instabile, quindi, benché spesso vengano rilasciati a basso prezzo o addirittura gratis, sarebbe buona norma non fondare i propri sistemi di lavoro su software in versione beta, o almeno passare alla versione completa e stabile appena è disponibile. Però anche gli utenti che collaudano il software ne hanno un vantaggio, perché non di rado le versioni beta sono abbastanza funzionanti da fare tutto ciò che gli utenti desideravano dal software completo, e possono così ottenere il programma gratis e in anticipo.
Candidate (rc)
Viene definita “Candidate Release” una particolare versione del software che prelude al rilascio di quella finale e stabile.
Generalmente la release candidate, abbreviata con rc, è rilasciata a sua volta in varie versioni (rc1, rc2, e così via), le quali si differenziano tra loro solo per la correzione dei bug ma non per l’introduzione di nuove funzionalità. Infatti, all’annuncio della pubblicazione di una rc, viene dato dal coordinatore del progetto lo stop allo sviluppo, e tutti gli sforzi da quel momento fino al rilascio della versione stabile vengono concentrati sulla risoluzione di eventuali problemi.
General Available (ga)
Viene definita “General Available” la versione di software pronta per la produzione e la distribuzione. Prende questo identificativo solo il primo rilascio con indice 0. Le successive modifiche vengono gestite come release maintenance.
Maintenance (r)
Viene definita “Maintenance” la versione di software successiva alla genral available release. In questa versione è possibile sono effettuare modifiche per la correzione di problemi od errori (bug), non è possibile aggiungere nuove funzioni o implementazioni.
La maintenace release, abbreviata con r, è rilasciata tante volte quanto viene richiesto per la risoluzione dei problemi o degli errori.
Elenco degli indici di release disponibili:
| Id | Descrizione | Utilizzo | Sigla | Esempio | ||||
| 0 | Not Applicable | Tutti i rilasci | na | 1.0.012.17 | ||||
| 1 | Alpha | Rilascio per test interno | a | 1.0.112.17 | ||||
| 2 | Beta | Rilascio per test esterno | b | 1.0.215.27 | ||||
| 3 | Candidate Release | Rilascio in test al cliente | rc | 1.0.34.48 | ||||
| 4 | General Available Release | Rilascio in produzione | ga | 1.0.40.76 | ||||
| 4 | Maintenance Release | Aggiornamento in produzione | r | 1.0.42.96 |
Indice di revisione (Revision)
Con indice di revisione si indica il numero di rilascio corrente relativo ad ogni release. Ad esempio dopo aver rilasciato la versione Beta con indice di revisione 0, ed aver corretto gli errori segnalati, il prossimo rilascio avrà come indice di revisione 1.
Ad ogni modifica dell’indice di istanza, si riparte dall’indice di revisione 0.
Indice di sorgente (SourceRevision)
Con questo indice si identifica la revisione attribuita dal controllo di codice sorgente quando si è compilato il programma. Il controllo di codice sorgente, come ad esempio SVN, attribuisce un numero univoco ad ogni “commit” effettuato.
Data di compilazione (BuildDate)
Indica il numero di giorni trascorsi dalla data 01/01/2001.
Ora di compilazione (BuildTime)
Indica il numero di minuti trascorsi dalla mezzanotte 00:00.
Registro delle modifiche (ChangeLog)
Il changelog è memorizzato in un file di formato testo e raccoglie, in ordine cronologico, tutti i possibili riferimenti di rintracciabilità di ogni modifica effettuata da una versione precedente ad una successiva di un software, fino al rilascio corrente.
Per ogni modifica, esso deve riportare tutte le modifiche e/o implementazioni effettuate all’interno del software, inserendo il riferimento e la descrizione al task interessato.
Oltre al file di testo allegato al programma di installazione e copiato nella cartella principale del programma, è possibile inserire una copia del registro all’interno del programma, sotto forma di pagina con hyperlink in modo da aprire direttamente i task interessati alle modifiche effettuate.
Le modifiche riportate nel registro sono identificabili come:
| New | Correzione di una funzione o procedura | |
| Fix | Correzione di una funzione o procedura | |
| Chn | Modifica di una funzione o procedura |
Esempio di ChangeLog di testo
L’esempio riportato di seguito mostra una parte del changelog creato per il progetto “Flash Invoice”. Il changelog deve essere in formato testo con estensione TXT (changelog.txt).
**************************************************************** * Project: Flash Invoice * Version: 1.0.32.58 * Date...: 2013-02-13 **************************************************************** Ver.: 1.0.32.48 - [Build: 2013-02-13] Fix FS#136 - UserName and CompanyName don’t show in Activation … Fix FS#170 - Document wrong error on print to pdf file Ver.: 1.0.31.45 - [Build: 2013-02-08] Fix FS#120 – Price unit field doesn’t saved … Fix FS#130 – Error when create new invoice with vat number blank *****************************************************************