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.

Carregando publicação patrocinada...
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.