Devo tratar restrições adicionais do linter como quebra de compatibilidade com versões anteriores?

5

Eu estou mantendo uma biblioteca de linter, então isso é basicamente um conjunto de regras verificadas contra algum código que se pode passar para ele. Digamos que temos a regra A , que verifica alguns casos.

Agora imagine que alguns commits estendem este conjunto - por extensão quero dizer que a cardinalidade do conjunto é maior, mas não membros "antigos" se foram, nós apenas adicionamos alguns novos membros.

Com relação à abordagem de versão semântica , como devo aumentar a versão secundária ou principal? A questão se resume a eu deveria considerar mudanças desse tipo como compatíveis com versões anteriores?

    
por shabunc 30.12.2015 / 03:10
fonte

1 resposta

4

Como é normal usar linters como parte de verificações contínuas de integração, eu diria que é correto pensar em adicionar novas regras de linter ativadas por padrão como uma possível quebra de mudança.

Se realmente é uma quebra, depende de como você espera que seu linter seja usado. Ou, em termos semânticos, o que você definiu como sua "API pública".

  • Se o seu linter é para ser usado com um arquivo de configuração que enumera todas as regras que devem ser habilitadas, então é razoável dizer que o comportamento sem um arquivo de configuração não tem garantias de compatibilidade com versões anteriores e você pode fazer qualquer coisa você quer mesmo em versões menores e menores.

  • Se o seu linter for usado com um arquivo de configuração que habilita e desabilita regras, mas não enumera o conjunto completo de regras ativadas, qualquer nova regra adicionada em um patch ou versão secundária deve ser desativada por padrão.

  • Se o seu linter não tiver nenhum arquivo de configuração e só puder ser configurado através de comentários no código-fonte, qualquer nova regra adicionada em um patch ou versão secundária definitivamente terá que ser desabilitada por padrão.

Por exemplo, um dos linters que minha equipe usa no trabalho em nossa configuração de IC é o JSCS (que se encaixa no segundo ponto) e com base em seu changelog , eles são legais em adicionar novas regras em versões secundárias, mas essas novas regras são desabilitadas por padrão (especialmente porque algumas delas são específicas do ES6). Eles também alteram suas "predefinições" em versões secundárias, que são essencialmente conjuntos alternativos de padrões. Como você precisa se esforçar para ativar uma predefinição, e eles seriam um recurso bastante inútil se nunca pudessem mudar depois de adicionados, é razoável não fornecer garantia de compatibilidade com versões anteriores para eles.

    
por 30.12.2015 / 11:49
fonte