O Versionamento Semântico (ou SemVer) é um padrão de regras utilizado para acompanhar versões de softwares durante seu desenvolvimento. O termo SemVer vem de Semantic Versioning, que significa Versionamento Semântico. Esse padrão fornece uma forma clara e consistente de comunicação sobre as mudanças realizadas no projeto, permitindo que desenvolvedores e usuários entendam facilmente o impacto de cada atualização.

Se você já instalou pacotes, frameworks ou softwares, certamente percebeu números como 1.2.3 ou 2.0.0. Essas sequências facilitam a compreensão do tipo de atualização feita, seja uma nova funcionalidade, uma correção de bug ou uma mudança crítica.

Formato do Versionamento Semântico

O SemVer segue o formato:

MAJOR.MINOR.PATCH

MAJOR (Versão Principal)

O primeiro número representa mudanças significativas no software que quebram a compatibilidade com versões anteriores. Isso pode incluir remoções ou alterações de funcionalidades, exigindo adaptações por parte dos usuários.

  • Exemplo: Atualizar de 1.4.2 para 2.0.0 indica mudanças importantes e potencialmente incompatíveis.

MINOR (Versão Menor)

O segundo número é atualizado quando novas funcionalidades ou melhorias são adicionadas sem afetar a compatibilidade com versões anteriores.

  • Exemplo: Atualizar de 1.4.2 para 1.5.0 mostra que novos recursos foram incluídos sem impacto no código existente.

PATCH (Correção de Erros)

O terceiro número é usado para indicar correções de bugs ou ajustes menores que não alteram o comportamento ou funcionalidades do software.

  • Exemplo: Atualizar de 1.4.2 para 1.4.3 reflete a correção de um problema sem mudanças estruturais.

Ciclo de Vida de Lançamento de um Software

Alpha

A versão Alpha é a primeira versão funcional do software, usada internamente pelos desenvolvedores para testes iniciais e validação de conceitos. É instável e geralmente indisponível para o público.

Beta

A versão Beta é mais completa e é disponibilizada para testes por um público maior, com o objetivo de identificar erros e coletar feedback. Embora funcional, ainda pode conter instabilidades.

Release Candidate (RC)

A versão Release Candidate é considerada estável e próxima da final. Se nenhum problema crítico for encontrado, ela se torna a versão oficial do software.

Exemplo Prático

Correção de Bug:

  • Versão atual: 1.0.0
  • Nova versão: 1.0.1 (PATCH)

Exemplo: Um erro em um endpoint foi corrigido sem afetar a compatibilidade.

Nova Funcionalidade:

  • Versão atual: 1.0.1
  • Nova versão: 1.1.0 (MINOR)

Exemplo: Um novo endpoint foi adicionado para gerenciar permissões de usuários.

Mudança Incompatível:

| Versão atual: 1.1.0
| Nova versão: 2.0.0 (MAJOR)

Exemplo: O modelo de autenticação foi completamente refatorado, exigindo ajustes nos sistemas que consomem a API.

Implementando SemVer com GitHub Releases

Criar uma Tag

Para marcar uma versão específica no repositório:

git tag -a v1.0.0 -m "Primeira versão estável"
git push origin v1.0.0

Criar uma Pré-Lançamento

Para criar uma versão de testes antes do lançamento oficial:

git tag -a v1.1.0-beta -m "Versão beta para testes"
git push origin v1.1.0-beta

Visualizar Histórico de Versões

Para listar todas as versões marcadas:

git tag

Dicas e Regras Essenciais

  • Use o formato MAJOR.MINOR.PATCH de maneira consistente.
  • Nunca altere uma versão já publicada.
  • Identifique versões de pré-lançamento com sufixos como -alpha, -beta ou -rc.
  • Documente as mudanças usando um arquivo como CHANGELOG.md.

Um CHANGELOG.md com formato padrão:

# Changelog

## [1.1.0] - 2025-01-20
### Adicionado
- Nova seção sobre integração com ferramentas CI/CD.
- Exemplos mais detalhados de uso com GitHub Actions.

## [1.0.0] - 2025-01-18
### Lançamento
- Conteúdo inicial sobre Versionamento Semântico.

Com o Versionamento Semântico, você pode comunicar mudanças de forma clara e eficaz, tornando o processo de desenvolvimento mais organizado e previsível.

Versão: 1.1.0

Author Of article : Higor Anjos Read full article