Re: Del criterio per cambiare il numero di release

Scusa Leonardo,
avevo capito male alcuni dettagli.

> 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 ?

No, in questo caso non si può, né si dovrebbe modificare la versione.
Pensavo che la modifica fosse stata fatta al file di configurazione
predefinito che viene fornito con l'applicazione, per cambiarne il
funzionamento senza ritoccare il codice. Un po' come succede coi giochi,
nei quali spesso il numero di versione comprende sia le modifiche al
codice del programma o motore, sia quelle ai dati, che possono cambiare,
alterando l'esperienza (interfaccia), senza però richiedere una modifica
al sorgente.

> 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.

La retrocompatibilità è una proprietà binaria conservativa: basta che ci
sia un singolo caso che muta l'esperienza dell'utente, per affermare che
la nuova versione non è retrocompatibile. Nel caso che descrivi, la
modifica non è retrocompatibile.

> 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 ?

Non ho capito quest'ultimo esempio, però a naso mi sembrerebbe che
l'errore stia nel non considerare entrambe le possibilità (macchina in
multiprocesso e non), piuttosto che scegliere quale componente del
numero di versione aggiornare. In teoria mi sembrerebbe possibile
risolvere questo problema, senza rompere la retrocompatibilità, senza
aggiungere nuove funzionalità, modificando solo il numero di patch.
Tuttavia non mi è chiaro se gli utenti si aspettassero che il programma
girasse a tutta randa, prima della correzione.