O que é versão semântica?

O controle de versão semântica é uma convenção formal para determinar o número da versão de novos lançamentos de software. O padrão ajuda os usuários de software a entender a gravidade das mudanças em cada nova distribuição.

Um projeto que usa versionamento semântico anunciará um número Principal, Secundário e Patch para cada lançamento. A string de versão 1.2.3 indica uma versão principal de 1, uma versão secundária de 2 e um número de patch de 3.

Os números de versão que usam esse formato são amplamente usados ​​por pacotes de software e executáveis ​​de usuário final, como aplicativos e jogos. Nem todo projeto segue exatamente o padrão estabelecido pela semver. org.

A especificação foi criada para resolver os problemas causados ​​por práticas inconsistentes de controle de versão entre pacotes de software usados ​​como dependências. Por “ pacote ” e “ dependência, ” estamos nos referindo a uma biblioteca de código que se destina a ser usada em outro projeto de software e é distribuída por um gerenciador de pacotes como npm, composer ou nuget. Esta é a aplicação de controle de versão semântica que estamos considerando neste artigo.

Principal, Secundário e Patch

É importante compreender o significado dos três componentes envolvidos. Juntos, eles traçam a jornada de desenvolvimento de um projeto e relacionam o impacto no usuário final de cada nova versão.

• Número principal – O número principal indica a versão atual da interface pública do pacote. Isso deve ser incrementado toda vez que você fizer uma alteração que exija que os usuários existentes de seu pacote atualizem seus próprios trabalhos.
• Número menor – O número menor descreve a versão funcional atual do seu software. Isso é incrementado sempre que você adiciona um novo recurso, mas não altera de outra forma a interface do seu pacote. Ele comunica aos usuários que uma mudança significativa foi feita, mas o pacote permanece totalmente compatível com o número anterior anterior.
• Número do patch – O número do patch é incrementado toda vez que você faz uma pequena alteração que não afeta a interface pública ou a funcionalidade geral do seu pacote. Isso é mais comumente usado para correções de bugs. Os consumidores devem sempre ser capazes de atualizar para a versão de patch mais recente sem hesitação.

A estrutura de lançamento de versão semântica é melhor modelada como uma árvore. No topo, você tem as alterações da interface pública, cada uma delas resultando em um novo número principal. Cada série principal tem seu próprio conjunto de versões secundárias, onde novas funcionalidades são adicionadas de maneira compatível com versões anteriores. Finalmente, versões menores podem receber patches de correção de bugs de tempos em tempos.

Por onde começar?

A maioria dos projetos deve usar 1.0.0 como sua versão inicial. Você está publicando sua primeira interface pública e um conjunto inicial inalterado de funcionalidades. Você ainda não precisou criar um patch, então a versão do patch é 0.

Vamos agora ver o que acontece quando você faz alterações no seu pacote. Após o lançamento inicial, você recebe um relatório de bug de um usuário. Quando você liberar a correção, o número da versão correta será 1.0.1. Se você criar outra versão de correção de bug, deverá aumentar o número do patch para 1.0.2.

Nesse ínterim, você também está trabalhando em um novo recurso empolgante. É totalmente opcional para que os usuários não precisem fazer nada para atualizar. Você libera isso como 1.1.0 – uma nova série funcional foi criada e você ainda não teve que corrigi-la. Infelizmente, relatórios de bugs chegam logo e 1.1.1 é enviado para seus usuários.

Vários meses depois, você decidiu refatorar o projeto inteiro. Algumas das funcionalidades que você costumava oferecer foram removidas ou agora são acessadas por meio de uma interface consolidada. Se você lançou este trabalho, as pessoas que usam a versão atual de seu pacote teriam que fazer grandes alterações em seus projetos. É hora de você publicar 2.0.0 em seu repositório de pacotes.

Mantendo ramos mais antigos

Bater em um número dentro da string de sua versão não cria um ponto sem volta. Depois de publicar 1.1.1, você pode descobrir um bug que também estava presente em 1.0.2. Usando branches em seu sistema de controle de origem, você pode aplicar o patch a ambas as versões. Você acabaria lançando 1.1.2 e 1.0.3.

Da mesma forma, você pode querer manter o branch 1.x do seu projeto, apesar de ter lançado 2.0.0. Pode parecer estranho publicar 1.1.2 após 2.0.1, mas essa é uma prática perfeitamente aceitável. O controle de versão semântico não cria um número de versão linear sempre incrementando; em vez disso, destina-se a ser usado como parte de um modelo de desenvolvimento ramificado que capitaliza na facilidade de correção oferecida por sistemas de controle de origem, como Git.

As versões publicadas devem ser imutáveis. Depois de criar uma versão, como 2.4.3, você não poderá “ atualizar ” simplesmente empurrando código adicional sob a mesma string de versão. Você deve atribuir um novo número de versão a cada lançamento, para que os usuários sempre possam acessar cada revisão específica de seu pacote.

Manuseio de pacotes de pré-lançamento

Normalmente, você sempre altera a versão principal do seu projeto sempre que uma alteração incompatível com versões anteriores é introduzida. Quando você está em um estado de pré-lançamento, sua base de código pode evoluir muito rapidamente, resultando na publicação de várias versões principais.

Você pode evitar isso anunciando seu projeto como 0.y.z para começar. Adotar 0 como sua versão principal indica que seu pacote é instável. As regras normais sobre alterações incompatíveis com versões anteriores não se aplicam mais, portanto, você pode publicar novos lançamentos incrementando apenas os números secundários e de patch. Isso significa que você ainda pode usar 1.0.0 para rotular o primeiro “ concluído ” versão do seu software.

Você também pode adicionar “ identificadores ” extras; ao final da string da versão, usando um hífen como separador: 1.0.0-alpha.1. Você pode usar isso para denotar claramente as variantes alfa e beta. Da mesma forma, você pode incluir metadados de compilação acrescentando o caractere +: 1.1.0-alpha.1 + linux_x86.

Conclusão

Fazer uso consistente de controle de versão semântica ajuda os usuários a ter confiança em seu projeto. Eles podem ver claramente como sua base de código está evoluindo e se eles precisarão trabalhar sozinhos para se manterem atualizados.

Anunciar uma string de controle de versão semântica é essencial quando você publica para os gerenciadores de pacotes mais populares. No entanto, em última análise, é sua decisão quais números você vai adotar para cada novo lançamento. Seguir o padrão comunica claramente suas intenções à comunidade e minimiza o risco de interromper involuntariamente o trabalho de outra pessoa.