Quale incremento della versione semantica utilizzare per modificare un file di configurazione?

Se è necessario distribuire nuove copie del software, quindi eseguire il bump della versione della patch. Il tuo log delle modifiche sarebbe

• Valore predefinito modificato della configurazione myTimeout su 1000

Hai anche bisogno di una modifica alla versione per una voce di configurazione? L'intero punto dei numeri di versione è di distinguere le modifiche del software, non i cambiamenti di dati.

Se insisti su una modifica della versione, o perché il tuo processo di distribuzione lo richiede o vuoi semplicemente tracciarlo, userei la granularità più bassa possibile (un numero di patch o un numero di build).

Semver si applica al controllo delle versioni delle API e delle librerie. L'intero punto di Semver è che puoi immediatamente vedere che puoi passare da una vecchia versione API x.y.a a una nuova versione x.z.b , a condizione che y ≤ z. Cioè: Semver standardizza una notazione per la compatibilità API.

Ciò significa che Semver non è immediatamente applicabile per applicazioni o altri prodotti che non offrono un'API. Ad esempio, l'uso di Semver per un'applicazione web sarebbe del tutto ridicolo; un singolo numero di implementazione incrementale è sufficiente se è necessario un numero di versione.

Come Ewan e 8bittree indicano che il punto dei file di configurazione è che possono essere modificati indipendentemente dal software.

• Se l'utente API modifica il file di configurazione, la versione dell'API non dovrebbe cambiare, tuttavia l'utente potrebbe aggiornare un numero di implementazione.
• Se il provider API crea una nuova versione con un file di configurazione predefinito aggiornato, quella versione necessita di una nuova versione. Tieni presente che i valori predefiniti aggiornati non influiscono in alcun modo sugli utenti esistenti, poiché dispongono già di un file di configurazione o il tuo processo di aggiornamento sovrascriverà le loro personalizzazioni?

Supponendo di avere un'API che meriti un numero di versione semantica e che la modifica del file di configurazione predefinito richiede una nuova versione e che i valori predefiniti aggiornati non influiscono sugli utenti esistenti con il proprio file di configurazione, quindi si dovrebbe < strong> incrementa il numero di patch . Perché?

• Il cambiamento è rilevante per gli utenti. Devono essere in grado di distinguere le versioni che hanno il nuovo valore predefinito nel file di configurazione. Ciò significa che la stringa della versione deve cambiare.
• Il numero di versione principale deve essere incrementato solo per le modifiche non compatibili all'indietro. Questo non è il caso qui.
• Il numero di seconde secondarie dovrebbe essere incrementato solo quando si aggiungono nuove funzionalità in un modo compatibile con le versioni precedenti. Non stai aggiungendo il nuovo comportamento.
• I metadati di generazione devono essere ignorati quando si confrontano le versioni, quindi non è il luogo in cui si possono significare le modifiche.
• Allo stesso modo, contrassegnare questo come una versione preliminare non aiuta qui.
• Pertanto: per esclusione, non esiste un altro luogo adatto ad eccezione del numero di patch per indicare la modifica predefinita della configurazione. I livelli di patch intesi per correzioni di errori non dovrebbero ostacolarti qui, è solo che le correzioni di bug sono il tipo più comune di cambiamento che non aggiunge o modifica il comportamento documentato.

Generalmente con modifiche al file di configurazione:

La versione del software non dovrebbe cambiare.

La versione della distribuzione dovrebbe cambiare.

dal momento che si configura il file di configurazione con il software, forse si potrebbe farlo separatamente?

Il controllo delle versioni basato su un valore in un file di configurazione sembra piuttosto ridicolo. Lo scopo di mettere le cose nei file di configurazione è di solito in modo che l'utente finale possa cambiarle se necessario senza aspettare per te e in modo da non dover mantenere un'applicazione unica per ogni singolo cliente.

Come ho detto nei commenti, hai davvero intenzione di battere il numero di versione ogni volta che un cliente cambia la configurazione? Sarà difficile se il cliente non te lo dice. Potresti fare in modo che l'applicazione torni a casa con eventuali modifiche, ma i difensori della privacy e della sicurezza non saranno contenti di questo, per non parlare del fatto che è un lavoro extra per tu da configurare.

E se non aggiorni il numero di versione ad ogni modifica, in realtà non ti dice nulla sui valori di configurazione, vero? Se stai cercando di eseguire il debug di un problema che stanno avendo, probabilmente dovresti esaminare la configurazione corrente, non quella che era per cinque minuti dopo l'installazione di un anno fa.

Se vuoi davvero aggiungere un po 'di rumore al tuo numero di versione, questa sembra la sezione più pertinente delle FAQ di SemVer:

What should I do if I update my own dependencies without changing the public API?

That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. I would usually expect additional code for the latter instance, in which case it’s obviously a minor level increment.

(Enfasi mia)

Poiché non c'è alcun nuovo codice coinvolto in questa modifica, ciò suggerisce un incremento del livello di patch.