Re: Del criterio per cambiare il numero di release

Ceppo <[email protected]> Thu, 6 Nov 2025 13:33:41 +0000
Newsgroups	gmane.linux.debian.user.italian
Message-ID	<66q4jfzh4cx34yowdcdjcu4yeby4v5lv366ohikwfeeix7domq@7bj3xbzilf7c>
On Wed, Nov 05, 2025 at 11:48:31AM +0100, Leonardo Boselli wrote:
> Quando si cambia il patch number della release e quando si deve 
> cambiare il minor ( del tipo 2.3.3 ...) ?-

Immagino che si parli di SemVer (https://semver.org/).

> - una nuova funzionalità introdotta modificando i file di 
> configurazione locale facendo fare al programma [di cui non tocchi 
> sorgente e binario] una cosa non prevista all'origine dal 
> programmatore e non documentata da luogo a un cambio di relese 
> [quale?] visto che si tratta di usa sola aggiunta alla documentazione

Se cambio solo la configurazione locale, come hai detto tu non sto 
modificando il software, quindi il numero della versione del software 
non cambia.
Se in questo modo faccio fare al software qualcosa di non previsto dallo 
sviluppatore, sto comunque (ab?)usando una funzione prevista, oppure sto 
sfruttando un bug non previsto ma comunque già presente.

> - una riscrittura del codice per favorire la leggibilità che influisce 
> solo la formattazione ma non cambia l'eseguibile

Patch si cambia "if only backward compatible bug fixes are introduced 
(...) that fixes incorrect behaviour." Riscrivere per leggiblità senza 
cambiare il comportamento è meno di questo, quindi non cambierei più di 
patch.
Ma se l'eseguibile non cambia non ha senso rilasciare una nuova 
versione, quindi il problema non si pone. Aspetto di introdurre altre 
modifiche e poi rilascio una nuova versione cambiando il numero di 
versione in base a quelle.
Considera che il numero di versione è rivolto all'utente, non agli 
sviluppatori. Se devo indicare a un altro sviluppatore che sto usando 
"il software dopo che ho fatto la modifica foo", meglio indicargli 
l'hash del commit in git.

> - una modifica dei valori di default che non cambia le funzionalità da 
> linea di comando o da file di configurazione

Se lo faccio *solo* per correggere un bug in modo retrocompatibile, 
cambio patch. Invece se così facendo *aggiungo* funzionalità senza 
*cambiare* quelle che già ci sono cambio minor.
Ad esempio, se la documentazione dice che il software foo salva i propri 
dati specifici per utente in $FOO_DATA e che il valore di default è 
$HOME/.local/share/foo:

- Se cambio il default di $FOO_DATA perché mi sono reso conto che per 
   sbaglio è $HOME/.local/share/bar, aumento patch.
- Se cambio il default di $FOO_DATA in $XDG_DATA_HOME/foo per supportare 
   la XDG Base Directory Specification, e mantengo $HOME/.local/share/foo 
   come fallback nel caso $XDG_DATA_HOME non fosse definito, aumento 
   minor.
- Se cambio il default di $FOO_DATA in $XDG_DATA_HOME/foo e *non* 
   mantengo $HOME/.local/data/foo come fallback, aumento major.


-- 
Ceppo
https://wiki.debian.org/Ceppo
Please, encrypt our messages with the key at the link above and send me yours.
signature.asc (application/pgp-signature, 833 B)