Versionamento del Framework DBS

Il versionamento del Framework DBS segue lo standard Semantic Versioning (SemVer) ed è basato su GitVersion 6. Il calcolo della versione è automatizzato e deriva dall'analisi della cronologia Git, dei tag e della struttura dei branch.

Obiettivi

L'adozione di GitVersion mira a raggiungere i seguenti risultati:

• Generazione automatica dei numeri di versione senza interventi manuali sui file di progetto o di configurazione.
• Unificare i processi di rilascio tra i diversi componenti del Framework.
• Garantire che ogni pacchetto distribuito sia associato in modo univoco e tracciabile a uno specifico commit nel repository.
• Assicurare la piena conformità allo standard SemVer per una gestione coerente delle dipendenze.

Logica di incremento per branch

GitVersion assegna un comportamento di versionamento specifico a ogni branch in base alla sua funzione nel ciclo di vita del software.

Branch	Destinazione	Incremento predefinito	Esempio versione
main	Produzione	Patch	1.0.1
develop	Sviluppo	Patch	1.0.1-alpha.5
hotfix/*	Correzione	Patch	1.0.1-beta.2

note

Per garantire una cronologia lineare, sia il branch di produzione che quello di sviluppo avanzano di default con incrementi di tipo Patch. I salti di versione di tipo Minor o Major devono essere gestiti tramite istruzioni esplicite durante il merge.

Sviluppo e integrazione

Durante la fase di sviluppo ordinaria sul branch develop, il sistema gestisce il versionamento in modalità non bloccante. Ogni push verso il repository remoto attiva il calcolo automatico della versione.

Il sistema applica il suffisso -alpha e incrementa il contatore dei commit rispetto all'ultimo rilascio stabile presente su main. Ad esempio, se l'ultima versione stabile è 0.10.0, i commit su develop produrranno versioni come 0.10.1-alpha.1, 0.10.1-alpha.2 e così via.

Rilascio di una nuova versione

Il passaggio dal branch develop al branch main tramite Pull Request (PR) determina la creazione di una versione stabile.

Incremento della versione (Bumping)

Per impostazione predefinita, il merge su main incrementa l'ultima cifra della versione (Patch). Se si intende procedere verso il rilascio di una versione ufficiale superiore, è possibile forzare l'incremento inserendo una stringa specifica nel messaggio del commit di merge in Azure DevOps:

• Minor: Inserire +minor nel messaggio (es. 0.10.x -> 0.11.0).
• Major: Inserire +major nel messaggio (es. 0.10.x -> 1.0.0).

important

Utilizzare gli override +minor o +major solo quando si è certi di voler far avanzare la versione ufficiale del Framework. Questo garantisce che la storia delle versioni sia coerente e priva di "buchi" o salti non voluti nella cronologia Git.

Applicazione del Tag di produzione

L'applicazione del tag Git sul branch main non è un'operazione automatica per ogni merge, ma deve essere eseguita solo quando si decide che una specifica versione proseguirà verso la produzione. Il tag funge da pietra miliare per cristallizzare il rilascio ufficiale.

Per applicare il tag manualmente sulla versione scelta:

# Esempio: si decide che la v0.11.0 è la versione per la produzione
git checkout main
git pull
git tag tiramisu-0.11.0
git push origin tiramisu-0.11.0

Sincronizzazione post-rilascio

Indipendentemente dall'applicazione del tag, dopo ogni merge su main è necessario riallineare il branch develop. Questo assicura che lo sviluppo futuro parta dalla base tecnologica più recente e che i metadati della versione siano sincronizzati.

git checkout develop
git merge main
git push origin develop

Risoluzione dei problemi

Versioni duplicate o incoerenti

In assenza di tag recenti, GitVersion continua a calcolare la versione basandosi sulla storia dei commit. Se si riscontrano anomalie, è probabile che i branch non siano sincronizzati o che manchi un tag su una versione precedentemente considerata "ufficiale".

In questi casi, applicare il tag mancante utilizzando il prefisso previsto per il componente:

• Per Tiramisu: git tag tiramisu-x.y.z

• Per le Libs: git tag libs-x.y.z

Rettifica della versione

Se un merge è stato eseguito senza l'override necessario (ad esempio è stata generata una Patch al posto di una Minor), è possibile "correggere" la percezione del sistema applicando il tag con la versione desiderata direttamente sul commit di main prima di procedere con la sincronizzazione di develop.