Oggi vorrei condividere il mio personale metodo per assegnare la versione software di una release al momento di un aggiornamento. Se non diversamente specificato, fa sempre comodo adottare uno standard per questo genere di cose.
Come è successo per il primo aggiornamento del software SqlDocGen, passando dalla versione 1.0.0.0 alla versione 1.0.0.1, la cifra che è stata cambiata già fa capire a colpo d'occhio cosa è stato cambiato dalla precedente.
Versionamento
Vediamo di schematizzare:
versione: W.X.Y.Z
W è la major version, per tutta la durata del ciclo di vita di una applicazione questo numero non cambia. No, non mi sono sbagliato, questo numero non cambia veramente! Un software sarà sempre con la medesima major version, il giorno in cui essa cambierà non sarà più il software di cui stavamo parlando fino a quel momento. Il cambiamento della major version si ha quando viene effettuato una riscrittura di una applicazione o un cambiamento radicale delle funzionalità per cui era stata prevista.
X è la minor version, indica una corposa modifica effettuata sul software. Prendendo per esempio il nostro software SqlDocGen, la sua minor version potrebbe essere aumentata il giorno in cui genererà documenti relativi a Database Oracle (spoiler?). Inoltre questo numero dovrebbe indicare una possibile non retro-compatibilità con le versioni precedenti.
Y è la feature version, indica una nuova funzionalità aggiunta nel software oppure un aggiornamento corposo per la risoluzione di bug gravi e sostanziosi. In alcune aziende questo numero può cambiare spesso prima della consegna al cliente, in modo da indicare quante feature sono state aggiunte.
Z è la build version, indica una risoluzione di piccoli bug, errori di configurazione, modifica di costanti e attributi statici, modifica di fogli di stile (webapp) o di manifest (mobileapp).
In ogni caso quando un numero maggiore cambia, quelli inferiori vengono impostati a zero; ad esempio dalla versione 1.2.3.4 si passa alla 1.3.0.0, in quanto la nuova release comprende le feature e bugfix precedenti.
In ogni caso quando un numero maggiore cambia, quelli inferiori vengono impostati a zero; ad esempio dalla versione 1.2.3.4 si passa alla 1.3.0.0, in quanto la nuova release comprende le feature e bugfix precedenti.
La data dell'ultima modifica
Dato che il settore dell'industria chimico-farmaceutica ha dei requisiti particolari, mi viene automatico inserire anche la data della release accanto al numero di versione anche sui software non farmaceutici.
Conclusioni
Se non vengono utilizzati software per il versionamento automatico del codice sorgente (SVN, CVS, Mercurial), può essere utile adottare un metodo standard per rilasciare numeri di versioni univoci ed autoesplicativi. Fatemi sapere quali altri metodi vengono utilizzati lasciando un commento a questo post o direttamente sulla pagina ufficiale Facebook.
Nessun commento:
Posta un commento