Um adendo de “sistemas” ao Versionamento Semântico

Resumo: Ao usar o versionamento semântico, considere não apenas alterações na API pública, mas também alterações nos requisitos do sistema.

O Versionamento Semântico concentra-se na assinatura pública da API, como determinante de quando mudar os números da versão. Se a API pública for alterada de maneira incompatível com versões anteriores, você colidiu então com o número da versão principal. Quando atualizo uma dependência para uma versão menor ou um pedaço dela, estou hipoteticamente assegurado de que a atualização será concluída com êxito, e que não terei que mudar nada sobre o meu sistema ou codebase existente.

Entretanto, penso que, enquanto a concentração da SemVer na API pública seja um indicador necessário para capacidade de atualização sem outras mudanças, ele não é um indicador suficiente.

Aqui está um cenário de atualização do mundo real:

1. O pacote 1.0.0 é lançado, dependente dos recursos disponíveis na Linguagem 4.0.0.
2. O pacote 1.1.0 é lançado, com uma API pública idêntica a 1.0.0, mas agora é dependente de novos recursos, disponíveis apenas na Linguagem 4.1.0.

SemVer é homenageado aqui pelo Pacote e pela Linguagem. Nenhum deles introduziu alterações de API’s públicas incompatíveis com versões anteriores: a API do Pacote está inalterada e a API da Linguagem adiciona novos recursos compatíveis com versões anteriores.

Mas agora, os internos do pacote dependem dos novos recursos da Linguagem. Assim, não é possível que os consumidores do Pacote 1.0.0 atualizem para o Pacote 1.1.0 sem que também atualizem para a Linguagem 4.1.0. Se tentarem atualizar, o sistema irá quebrar, mesmo que o SemVer indique que deve ser seguro atualizar.

Parece que há mais compatibilidade com versões anteriores do que apenas a API pública.

II

Alguns argumentarão que, quando os requisitos do pacote são especificados corretamente em um manifesto de pacotes, o gerenciador de pacotes evita que ocorra uma quebra no cenário acima. O gerenciador de pacotes, ao ler o manifesto, notará que a Linguagem 4.1.0 não está instalada e se recusará a atualizar o Pacote de 1.0.0 para 1.1.0.

No entanto, este não é o ponto que estou tentando trazer aqui. O gerenciador de pacotes impede a quebra de instalações com base em um manifesto, sim. Porém, essa prevenção não significa que as alterações introduzidas no Pacote 1.0.0 sejam compatíveis à versões anteriores com o 1.1.0. As alterações 1.1.0 requerem uma modificação do sistema devido a uma incompatibilidade de requisitos.

Portanto, é verdade que o gerenciador de pacotes fornece uma defesa contra quebras, mas também é verdade que o número de versão do pacote não indica a existência de uma incompatibilidade com versões anteriores em relação ao sistema existente. É a indicação de incompatibilidade, que torna o SemVer valioso.

III

Eu acredito que exigir uma alteração no ambiente público em que um pacote é instalado, é uma incompatibilidade tão importante quanto a introdução de uma mudança de quebra na API pública do pacote. Para complementar esse caso, eu ofereço o tópico a seguir como um adendo preliminar para as especificações do SemVer:

• Se o consumidor do pacote tiver que mudar um recurso de sistema acessível ao público para atualizar um pacote, então a atualização do pacote não é compatível com versões anteriores com o sistema existente e o pacote deveria receber uma colisão da versão principal.

O uso de “deveria” faz com que essa regra seja um pouco menos rigorosa do que o deve de uma colisão da versão principal ao alterar a API do pacote. É possível que a Linguagem 4.0.0 não seja mais suportada ou instalada em nenhum dos sistemas alvo, sendo razoável que uma versão menor do Pacote exija uma alteração na versão da Linguagem. Porém, você precisa ter um bom motivo técnico ou prático – não de mercado –  para evitar a colisão da versão principal ao alterar os requisitos do sistema público para o pacote.

(Você também pode querer rever o Versionamento Romântico para uma tomada adicional no Versionamento Semântico.)

Você está preso a um aplicativo PHP legado? Você deve comprar o meu livro, porque lhe dá um guia passo a passo para melhorar seu codebase, e tudo isso, mantendo-o funcionando o tempo todo.

***

Paul. M. Jones faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela Redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://paul-m-jones.com/archives/6661

Powered by WPeMatico