Nel contesto del versioning semantico, una modifica della configurazione di default richiede una nuova versione principale?

Question

Nel contesto del versioning semantico, una modifica della configurazione di default richiede una nuova versione principale?

#1 da (7 voti)
#2 da (-1 voti)

5

Il mio modulo è abilitato di default (cioè quando aggiungi il modulo). C'è anche una configurazione che puoi usare facoltativamente , che supporta un'impostazione enabled="true|false" . In questo modo il modulo può essere disattivato dopo essere stato aggiunto, senza la necessità di rimuovere il modulo.

Ma ho realizzato che il modulo non funziona bene con un altro modulo che è anche abilitato di default. Sto considerando di cambiare il mio modulo in modo che non sia abilitato di default. Ciò si interromperà per chiunque non l'abbia abilitato esplicitamente con l'impostazione di configurazione enabled="true" .

Dovrei aspettare la v2.0 per questo? semver.org menziona l'API pubblica e interrompe le modifiche, non la configurazione. È generalmente accettato che la configurazione sia parte dell'API pubblica?

versioning .net configuration semantic-versioning

posta Michiel van Oosterhout 05.02.2012 - 22:48

fonte

2 risposte

-1

Non è un cambiamento semantico, quindi stai bene cambiando questo (non è davvero un cambiamento di rottura che costringe le persone a ricompilare e testare). Questo è fondamentalmente un interruttore ei tuoi utenti hanno la possibilità di cambiarlo in base alle proprie esigenze. Ecco perché hai fatto la configurazione per cominciare. Non hai cambiato la natura di ciò che è vero / falso.

Basta essere gentili e aggiungerlo alle note disattivate per impostazione predefinita, hehe.

risposta data 05.02.2012 - 23:45

fonte

Leggi altre domande sui tag versioning .net configuration semantic-versioning

Implementazione del Principio di Responsabilità Singola Dato un set di chip VLSI, come posso determinare quali sono buoni?

score 7 · Accepted Answer

Prenderò in considerazione qualsiasi modifica che costringa un utente a modificare il proprio codice / configurazione come risultato di un cambio di rottura.

Quindi, in questo caso particolare, aspetterei fino alla v2 di introdurre il valore predefinito di enabled=false e invece aggiungerei una nota nella prossima versione secondaria che spiega questo scenario noto, che dovresti impostare in modo esplicito enabled=false per evitare e che la prossima versione principale la risolverà.