Versionamento semântico

• Em inglês: semantic versioning
• Abreviação: SemVer

O versionamento semântico é um esquema de versionamento que transmite significado sobre o código por trás e sobre o que foi modificado de uma versão para a seguinte. Ele ajuda os desenvolvedores a entender o impacto de atualizar para uma nova versão de uma biblioteca ou aplicação.

O versionamento semântico se baseia nos seguintes princípios:

1. Formato do número de versão. O versionamento semântico usa um número de versão em três partes, no formato MAJOR.MINOR.PATCH. Por exemplo, 2.1.7 indica a versão major #2, a versão minor #1 e o patch #7.

2. Retrocompatibilidade. Uma nova versão MINOR ou PATCH deve ser retrocompatível com a versão anterior. Isso significa que o código escrito para uma versão mais antiga deve funcionar com a nova versão sem modificações.

3. Incremento do número de versão. Ao fazer alterações em uma biblioteca ou aplicação, o número de versão deve ser incrementado de acordo com o tipo de alteração:

• Versão major: Incrementada quando há mudanças incompatíveis na API.
• Versão minor: Incrementada quando funcionalidades são adicionadas de forma retrocompatível.
• Versão de patch: Incrementada quando há correções de bugs retrocompatíveis.

Digamos que você tem uma biblioteca na versão 1.2.3. Se fizer uma alteração que adiciona funcionalidade nova de forma retrocompatível, você incrementa a versão para 1.3.0. Se fizer uma alteração que corrige um bug de forma retrocompatível, incrementa a versão para 1.2.4. Se fizer uma alteração que introduz uma mudança incompatível na API, obrigando quem já usa a sua biblioteca a mudar algo no código, incrementa a versão para 2.0.0.

O conceito de versionamento semântico está integrado aos gerenciadores de pacotes modernos, como npm, pip, composer e outros. Quando você adiciona uma biblioteca de terceiros ao projeto, pode especificar um intervalo de versões para garantir que vai receber as correções de bugs e as funcionalidades mais recentes sem quebrar o seu código por causa de mudanças incompatíveis. Por exemplo, se você especificar o intervalo de versões ^1.2.3, vai receber qualquer versão que seja 1.x.x e tenha versão de patch pelo menos 3. Assim você recebe automaticamente as versões de patch e minor mais recentes, sem mudanças que quebrem o código.

Outros tipos de números de versão e rótulos

Além das versões numéricas, você também pode encontrar outros tipos de versões, números e rótulos no mundo do software:

• Número de build: Uma build é o processo de transformar código-fonte em um programa executável ou uma biblioteca. Compilar o código, rodar os testes e empacotar o resultado em um formato distribuível fazem parte do processo de build. Quanto mais complexo o software, mais etapas o processo de build envolve. Para algo como um sistema operacional, o processo de build pode levar horas ou até dias. A própria infraestrutura de build pode ser bem complexa e pode causar bugs no produto final, então é importante ter um histórico de builds e conseguir reproduzi-las. É por isso que, em projetos de software complexos, cada build recebe um número de build único. Os números de build costumam ser sequenciais e podem ser usados para identificar uma build específica do software. Por exemplo, 1.0.0-build123 se refere à 123ª build da versão 1.0.0. Os números de build costumam ser usados internamente pelas equipes de desenvolvimento e não são expostos aos usuários finais; ainda assim, você pode vê-los em alguns programas.

• Nightly: Versões construídas automaticamente toda noite a partir do código mais recente do repositório (ex.: 1.0.0-nightly.20220315). As versões nightly costumam vir acompanhadas de uma data ou de um número de build. Essas versões normalmente são usadas por desenvolvedores para testar as funcionalidades e correções de bugs mais recentes e reportar problemas à equipe de desenvolvimento.

• Alpha: Versões que ainda estão em desenvolvimento ativo e ainda não são estáveis (ex.: 1.0.0-alpha.35). Elas costumam ser lançadas para colher feedback antecipado dos usuários. Qualquer build nightly pode ser promovida a versão alpha se for considerada estável o bastante para testes.

• Beta: Versões mais ou menos prontas e estáveis, mas ainda não consideradas prontas para produção (ex.: 1.0.0-beta.1). Essas versões costumam ser liberadas para um grupo seleto de usuários (chamados de beta testers), geralmente voluntários ou funcionários, para testar o software em condições reais e eliminar os bugs restantes.

• Release Candidate (RC): Versões consideradas estáveis e prontas para produção, mas que ainda precisam ser testadas por um público maior (ex.: 1.0.0-rc.1). Essas versões costumam ser liberadas ao público para colher feedback de um grupo maior de usuários. Se nenhum problema grave for encontrado, a versão RC é promovida a release final.

• Stable: Versões consideradas estáveis e prontas para produção (ex.: 1.0.0). Essas versões são liberadas ao público e recomendadas para uso geral.

• LTS (Long-Term Support): Versões com suporte por um período estendido (ex.: 1.0.0-lts). Essas versões costumam ser mantidas por vários anos e recebem atualizações de segurança e correções de bugs. Claro, nem todo software tem ou precisa de versões LTS. Elas são mais comuns em softwares grandes, como bibliotecas, frameworks ou sistemas operacionais amplamente usados em ambientes de produção. Quem usa esse software em produção precisa ter certeza de que pode contar com ele por muito tempo e de que ele vai receber atualizações de segurança e correções de bugs.