Re: Del criterio per cambiare il numero di release

On Sat, 8 Nov 2025, Matteo Bini wrote:

> Buonasera Leonardo,
> dando per scontato che il programma di cui hai chiesto segua i dettami
> del versionamento semantico [1], che corrispondono a quanto hai citato,
> di seguito le mie tre risposte.
> 1. Se si aggiunge una funzione modificando il file di configurazione,
>   senza toccare né sorgente né binario, di fatto stiamo aggiungendo una
>   funzionalità del programma retrocompatibile con l'interfaccia
>   pubblicata in precedenza. Si tratta di un caso di modifica minore,
>   seppur estremo, perciò aumenterei la componente Y del numero di
>   versione.

il file di configurazione è quello che l'utilizzatore passa chiamando il 
programma con

$ programma -c config.ini

poiché il cambio del contenuto è fatto dall'utente la vedo dura seguire il 
numero di minor version ... una per ogni esecuzione ?

> x.Y.z

> 3. Non riesco a immagine come la modifica dei valori predefiniti possa
>   essere retrocompatibile con l'interfaccia. Ammesso che lo sia, ma è
>   più facile che non sia così, si tratterebbe pur sempre di un caso
>   analogo al precedente, di ottimizzazione della parte privata del
>   codice. Anche in questo caso farei aumentare la componente Y della
>   versione.

In questo caso i valori predefiniti sono quelli che possono essere 
modificati nel file config.ini . per chi passa tuttil config non cambia 
nulla, mentre cambia se uno lancia il programma senza parametri.
Da qui il dubbio se cambiare o meno minor version visto che cambia per 
qualcuno e per qualcunaltro no.

mi è venuto in mente un quarto caso visto che ho letto pochi minuti fa su 
un altro forum la lamentela di un utente che dopo on bug fix si è trovato 
il funzionamento del programma che usava di più fortemente rallentato. Gli 
hanno risposto che ciò era dovuto alla "correzione di un bug" in quanto 
a quel programma consentiva di utilizzare tutte le risorse del computer, 
non consentendo ad altre applicazioni di girare, e quindi era stato 
introdotto un limite che se l'uso cpu superava il 25% in media per 20 
secondi il programma veniva fermato per 5 secondi.
Qualcuno ha scoperto che se il programma gira per 5 secondi siccome il 
contatore pare faccia totalizzare il tempo CPU per 20 secondi, non 
supererà mail il 25% di 20 secondi anche se gira al 100% e ha modificato 
lo script di avvio in maniera che non giri per 24 ore ma che ogni 5 
secondi esca e riparta immediatamente.
Il bug chiaramante è per chi usa la macchina in multiprocesso, ma se il 
programma che succhia tempo CPU è l'unico a girare non lo è mentre lo è la 
patch. In questo caso dovendo in un certo caso modificare gli script di 
avvio è giusto che cambi minor release e non solo il livello di patch ?

> Spero di essere stato di aiuto.
>
>
> [1] https://semver.org/
>
> -- 
> Matteo Bini
>
>

--
Leonardo Boselli
Firenze, Toscana, Europa
http://i.trail.it
tel:+393287329225