Thread by @rochacbruno

Percebi que grande parte dos projetos que usa versões x.y.z não segue de verdade o versionamento semântico.

Dá trabalho sim, mas é possível fazer múltiplos releases e em ordem cronológicas completamente distintas, e o mais importante: manter a compatibilidade reversa.

🧵

Versão inicial 0.1.0

Na branch main:

- Nova feature super legal
- Outra feature nova que ainda precisa de mais testes
- Bugfix que não influencia na experiência de uso
- Bugfix que altera parametros de função
- Security patch
- Disable a magic function

+ backlog enorme.

🧵

Não precisa ficar esperando o backlog estar todo resolvido ou a branch main estar toda estável para fazer um release 0.2.0.

Para isso existe o z-stream e o cherry picking

🧵

Cria uma branch 0.1.1, esse release vai incrementar apenas o .z, ou seja, patch, não pode incluir nem novas features, nem quebras de compatibilidade, precisamos pegar da main só aquilo que se encaixa.

git cherry-pick <commits-selecionados> ...

🧵

Digamos que para a 0.1.1 pegamos apenas:

- Bugfix que não influencia na experiência de uso
- Security patch

Fazemos o release da 0.1.1 QUE NÃO INCLUI TUDO QUE ESTÁ PRONTO NA MAIN.

🧵

Agora sim a vida continua, nosso próximo milestone é agora o 0.2.0 onde provavelmente estarão inclusas:

- Nova feature super legal
- Outra feature nova que já foi testada
- Bugfix que altera parametros de função mas não quebra compatibilidade

🧵

Ok mas e o item:

- Disable a magic function

A semver diz:

MAJOR (X) quando a mudança quebra compatibilidade.
MINOR (Y) quando nova funcionalidade é adicionada ou mudança que não quebra compatibilidade.
PATCH bug fix, security fix, que não quebra compatibilidade.

🧵

Remover uma funcionalidade do projeto é uma mudança que gera quebra de compatibilidade, pode ter gente usando essa funcionalidade que vai ter prejuízos se lançarmos isso em um release minor, portanto aqui é onde fazermos o bump do X.

Aqui fazemos o release da versão 1.0.0

🧵

Isso é muito importante! pois dependentes podem especificar as dependências usando:

~=3.1: 3.1 ou maior, mas não 4.0
== 3.1.*: que comece com 3.1. .
~=3.1.0, != 3.1.3: 3.1.0 ou maior, exceto 3.1.3 nunca 3.2.0 ou maior.
>=3,<=4 entre 3 e 4

python.org/dev/peps/pep-0…

🧵

Quando usar versionamento semântico? sempre que alguém dependa de usar ou integrar com o seu projeto.

A compatibilidade reversa é uma das coisas mais importantes, pois mesmo que a sua lib tenha um bug, pode ter gente usando esse bug como feature ;/

🧵

E você pode tornar seu projeto menos estável na tentativa de resolver um bug que tenha side effects (regressions) em outras funcionalidades.

Para organizar isso pode usar a ajuda de testes de mutação e de integração.

🧵

semver é uma forma efetiva de comunicação com todos que dependem da sua lib, sejam humanos ou sejam sistemas de build e processamento de dependências.

🧵

Toda vez que vc lança um projeto usando x.y.z (semver.org) implicito está um "contrato" dizendo: Pode confiar, integrar, testar, usar que se eu quebrar a compatibilidade eu aviso antes na hora que eu mudar o X.

🙏

Um detalhe: existem projetos que por questões de marketing, decidem usar a semver parcial, onde
X = versão marketeira do produto
Y = Major que quebra compatibilidade
Z = novas feats, bug fix que não quebra compatibilidade.

Isso deve estar bem especificado na doc do projeto.

Nota: isso se aplica a frameworks, bibliotecas, plugins etc.. software que será integrado a outro software.

Para aplicativos de ponta (bem notado pelo @haggen) o mais comum é versionamento cronológico: chronver.org (ano.mes.dia.release)

Ex: Ubuntu 20.04

Esse é um baita assunto, interminável, mas outro ponto importante é que tem projetos que preferem ficar na varsão `0.y.z` e nunca irem para `1.y.z` pois o `0` dá a noção de beta, de "os riscos são por sua conta".

Curiosidade:

O criador da especificação SemVer é o mesmo que criou o TOML, o Jekyll, Chronic e é co-fundador do github.