Del criterio per cambiare il numero di release

dopo due giorni impazzendo nel debug di un programma fatto a un altro, che 
mi aveva mandato da provare non avendo lui la stessa configurazione 
che ho io (che è un po' atipica), per scoprire che mi aveva mandato un 
eseguibile "scompagnato" dai file di configurazione mi è venuta questa 
domanda:
Quando si cambia il patch number della release e quando si deve cambiare 
il minor ( del tipo 2.3.3 ...) ?-

trovo scritto:

“
Patch version Z (x.y.Z | x > 0) MUST be incremented if only backward 
compatible bug fixes are introduced. A bug fix is defined as an internal 
change that fixes incorrect behavior.

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward 
compatible functionality is introduced to the public API. It MUST be 
incremented if any public API functionality is marked as deprecated. It 
MAY be incremented if substantial new functionality or improvements are 
introduced within the private code. It MAY include patch level changes. 
Patch version MUST be reset to 0 when minor version is incremented.
”

ma:
- 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 ?
- una riscrittura del codice per favorire la leggibilità che influisce 
solo la formattazione ma non cambia l'eseguibile
- una modifica dei valori di default che non cambia le funzionalità da 
linea di comando o da file di configurazione

come le considerate ?

--
Leonardo Boselli
Firenze, Toscana, Europa