Numeri di versione: come leggere major, minor e patch
Di Redazione Quaderno dei Sistemi
Comprendi la convenzione SemVer senza presumere che ogni programma la adotti. Con un esempio di cambiamento incompatibile e una lista di controlli.
Un numero come 2.4.1 non ha un significato universale indipendente dal progetto. Se il progetto dichiara di seguire Semantic Versioning, le tre parti indicano major, minor e patch rispetto alla sua API pubblica. Prima di dedurre la compatibilità, verifica quindi quale politica di versione è documentata.
La convenzione e il suo perimetro
SemVer associa gli incrementi major a modifiche incompatibili dell’API, minor ad aggiunte compatibili e patch a correzioni compatibili. Questa distinzione richiede un’interfaccia pubblica definita. Non prova che ogni ambiente sia stato testato né che un aggiornamento sia privo di errori.
Un esempio da discutere
Immagina un programma che esporta una colonna chiamata «data». Rinominare quella colonna può interrompere un altro processo che la cerca con il vecchio nome. Se l’export appartiene all’interfaccia promessa, la modifica merita attenzione alla compatibilità. L’esempio non assegna automaticamente un numero: occorre conoscere il contratto del progetto.
Cosa annotare prima di aggiornare
Registra versione installata, versione proposta, politica dichiarata e cambiamenti che toccano il tuo utilizzo. Poi scegli un file di prova rappresentativo. Il solo salto numerico non sostituisce la lettura delle note e la verifica del risultato che ti serve.
Evita inoltre di confondere una data, un numero di build e una versione semantica. Sono identificativi con scopi diversi. In un inventario possono convivere, purché ciascuna colonna abbia un nome esplicito e non venga presentata come una garanzia di compatibilità.