0
lfnsilva
2 min de leitura ·

Tag antes do bump: o que achei nas tags de 2026 de 1.200 repositórios

Um erro de release bem comum: você cria a tag v1.16.0 e só depois sobe a versão no arquivo. A tag fica apontando para um commit que ainda diz 1.15.2.

Na maioria das vezes nada quebra na hora. Mas quem faz git checkout v1.16.0 recebe outro código, e alguns registros de pacotes guardam o commit de onde a versão saiu de verdade, que não é o da tag.

Rodei uma checagem nas tags criadas em 2026 em cerca de 1.200 repositórios públicos: PyPI, crates.io, npm, RubyGems, apps do F-Droid, Helm, Flutter e os mais estrelados do GitHub. A pergunta para cada tag: ela nomeia a versão que o próprio commit declara?

Alguns casos reais, todos conferíveis em dados públicos:

  • smallvec (Rust): a tag v1.16.0 aponta para um commit com 1.15.2. O crates.io registra no .cargo_vcs_info.json que a 1.16.0 saiu de outro commit.
  • pytest-timeout: a tag 2.5.0 saiu com 2.4.0 no setup.cfg. O commit seguinte diz "should have been committed before the tag". A 2.5.0 foi retirada (yanked) do PyPI.
  • ComfyUI: três tags do ano saíram antes do bump; a release v0.14.2, cuja tag declara 0.14.1, traz pacotes portáteis para Windows.

O mais interessante foi o erro da minha própria checagem. A maioria dos descasamentos era falso positivo: monorepo com tag de outro pacote (clap_complete-v4.6.1), pré-release escrita de dois jeitos (v2.9.0-rc0 e 2.9.0rc0), build metadata (+45). Nada disso aparecia no corpus antigo de testes, que fica congelado em tags velhas. Medir fora do laboratório pegou o que o laboratório não pegava.

Um cuidado: perdi os arquivos brutos da varredura, então não dou taxa nenhuma. Só os casos conferidos à mão.

Se quiser evitar o problema no seu projeto: crie a tag depois do commit que sobe a versão, ou faça o workflow de release criar a tag a partir do arquivo de versão.

A checagem é o --tag do closure_drift, ferramenta minha, open source. O registro completo, com os comandos para conferir cada caso: https://doi.org/10.5281/zenodo.24054343

Carregando publicação patrocinada...
1

Eu criei algumas tags em repositórios no github mas já faz algum tempo. Era em situações que eu experimentei usar o recurso 'releases' da página principal do repositório. Eu senti dificuldade em manter disponível os arquivos corretos com as identificações corretas.

1

É bem isso: a página de releases mostra o nome da tag, mas o arquivo anexado foi gerado de onde? Se a tag foi criada antes de subir a versão, o pacote sai com o número antigo.

O que resolveu para mim:

  1. Subir a versão no arquivo, commitar, e só depois criar a tag.
  2. Deixar o workflow do GitHub Actions gerar os arquivos da release a partir da tag, em vez de anexar à mão.
  3. Antes do push da tag, conferir se ela bate com a versão do arquivo. É o que o --tag faz: python3 closure_drift.py --tag v1.2.0.

Se quiser, roda nos seus repositórios antigos e me conta o que apareceu.

1

Cara
Eu estou procedendo errado:
Nos dois repositórios que ofereço executável (windows) eu não crio nem release nem tag
Eu os ofereço com um link que eu 'peguei' do botão verde 'code -> download ZIP' da página principal do repositório

botão verde

2

Não chega a ser errado, mas tem um efeito: esse link baixa o ZIP do branch como ele está agora. Quem baixou ontem e quem baixa hoje recebem coisas diferentes pelo mesmo link, e nenhum dos dois sabe qual versão tem.

Um jeito simples de fixar:

  1. Cria uma release (ex.: v1.0.0) no repositório e anexa o .exe ou o .zip nela.
  2. No lugar do link do botão verde, usa https://github.com/SEU_USUARIO/SEU_REPO/releases/latest/download/NOME_DO_ARQUIVO.zip, que sempre aponta para o arquivo da última release.
  3. Se o programa mostra a versão em algum lugar, confere que é a mesma da tag antes de publicar.

Assim cada versão tem nome, e dá para voltar a uma anterior se a nova der problema.