Poiché è normale utilizzare i linters come parte di controlli di integrazione continui, direi che è corretto pensare di aggiungere nuove regole di linter abilitate per impostazione predefinita come una modifica potenzialmente inefficace.
Che sia in realtà un cambiamento di rottura dipende da come ti aspetti che il tuo linter sia usato. O in termini di semere, ciò che hai definito come la tua "API pubblica".
-
Se il tuo linter è pensato per essere usato con un file di configurazione che enumera ogni singola regola che deve essere abilitata, allora è ragionevole dire che il comportamento senza un file di configurazione non ha garanzie di compatibilità con le versioni precedenti e puoi fare qualunque cosa vuoi anche nelle patch e nelle versioni secondarie.
-
Se il tuo linter è pensato per essere utilizzato con un file di configurazione che abilita e disabilita le regole, ma non enumera il set completo di regole abilitate, tutte le nuove regole aggiunte in una patch o versione secondaria devono essere disabilitate di default.
-
Se il tuo linter non ha alcun file di configurazione e può essere configurato solo tramite commenti nel codice sorgente, tutte le nuove regole che aggiungi in una patch o versione secondaria devono essere disabilitate di default.
Ad esempio, uno dei lint che il mio team utilizza al lavoro nella nostra configurazione CI è JSCS (che rientra nel secondo punto elenco) e basato su loro changelog , sono fantastici con l'aggiunta di nuove regole in versioni minori, ma quelle nuove regole sono disabilitate di default (soprattutto perché alcune di esse sono specifiche per ES6). Cambiano anche i loro "preset" in versioni minori, che sono essenzialmente insiemi alternativi di default. Dal momento che devi fare di tutto per abilitare un preset, e sarebbero una funzione piuttosto inutile se non potessero mai cambiare una volta aggiunto, è ragionevole non fornire alcuna garanzia di retrocompatibilità per loro.