Toda atualização de app traz um número: 1.0.0, 1.1.0, 2.0.3. Quando ele é escolhido ao acaso, ninguém entende o que mudou. O versionamento semântico, conhecido como SemVer, é uma convenção que dá significado a cada parte do número.
As três partes
O formato é MAJOR.MINOR.PATCH. Em 3.7.2, o 3 é major, o 7 é minor e o 2 é patch.
- Major: sobe quando a mudança quebra a compatibilidade. Algo que funcionava de um jeito deixa de funcionar, como um formato de arquivo que mudou ou um recurso removido.
- Minor: sobe quando você adiciona uma função nova sem quebrar o que existia.
- Patch: sobe quando só corrige um erro, sem recurso novo.
Ao subir uma parte, as à direita voltam a zero. De 1.4.3 com recurso novo vai para 1.5.0. De 1.5.0 com uma quebra vai para 2.0.0.
Exemplo prático
Imagine um app de lista de tarefas:
- 1.0.0: primeira versão pública.
- 1.0.1: corrige um erro que fechava o app ao abrir uma lista vazia.
- 1.1.0: adiciona lembretes, sem mudar nada do que existia.
- 2.0.0: muda o formato de armazenamento e exige que o usuário migre seus dados.
Para quem usa uma biblioteca sua, o número diz se atualizar é seguro (patch), provavelmente seguro (minor) ou exige atenção (major).
Versão e build nas lojas
Nas lojas de aplicativos, normalmente há dois campos: o número de versão, que o usuário vê, e um número de build ou código interno, que precisa aumentar a cada envio. Os nomes exatos mudam conforme a loja. Você pode usar SemVer para o primeiro e um contador simples para o segundo.
Boas práticas
- Registre as mudanças em um arquivo de notas de versão, com o que entrou, o que foi corrigido e o que quebrou.
- Marque cada versão publicada com uma tag no repositório, o que ajuda a voltar a um ponto conhecido. Se você ainda está começando com isso, veja Git e GitHub para iniciantes.
- Não reaproveite um número já publicado com conteúdo diferente.
- Em fase inicial, versões 0.x indicam que tudo pode mudar. Passe para 1.0.0 quando decidir manter a compatibilidade.
SemVer não resolve tudo. Cabe a você decidir o que conta como quebra, e usuários diferentes podem discordar. Escreva essa regra no projeto para que a equipe aplique o mesmo critério.
