release

name	release
description	Lança uma nova versão do SAPOS — merge na main, tag anotada, label e issues no GitHub, release publicada. Use quando um ramo estiver homologado e pronto para virar versão, ou quando precisar conferir como as releases anteriores foram feitas.

Release do SAPOS

Sequência para transformar um ramo pronto em versão publicada. O passo final — o deploy em produção — é do mantenedor; a skill vai até a release no GitHub.

Pré-requisitos

Não comece sem isto:

• Suíte completa verde no ramo (bundle exec rspec, ~12 min).
• Homologação feita, quando a mudança toca o que a suíte não alcança (skill homologacao).
• Passada manual do mantenedor em staging, quando houver caminho de escrita, PDF, planilha ou e-mail envolvido — a captura automatizada é só leitura.
• main sincronizada com origin/main: git rev-list --left-right --count origin/main...main → 0 0.

Passos

1. Levante o que sai na release

git log --oneline <tag_anterior>..<ramo>
git log <tag_anterior>..<ramo> --format='%h %s%n%b' | grep -iE '#[0-9]+' | sort -u

Separe as issues atendidas das apenas citadas. Um commit que diz "isso fica para issue própria (#626)" não atende a #626 — mencionar não é entregar.

Trabalho de vulnerabilidade não tem issue (ver AGENTS.md): vai aparecer como commits sem referência. Isso é esperado, e o passo 6 diz como descrevê-lo.

2. O número da versão

Quem define é o mantenedor. Se ele não informar, proponha o incremento de patch sobre a última tag (git tag -l --sort=-v:refname | head -3; 7.15.20 → 7.15.21) e peça confirmação antes de criar a tag — o incremento pode não ser de patch.

3. Merge na main, fast-forward

git checkout main
git merge --ff-only <ramo>
git push origin main

O --ff-only é proposital: pelo modelo de ramos (CONTRIBUTING.md), o ramo já mergeou a main nele antes do PR, então o merge tem que ser fast-forward. Se o git recusar, não force nem faça merge commit — o ramo está desatualizado e precisa integrar a main primeiro, com a suíte rodada de novo.

Nem toda release passa por PR; quando o mantenedor dispensa, o merge é direto.

4. Tag anotada

git tag -a 7.15.21 -m "7.15.21"
git push origin 7.15.21

Sempre anotada (-a), nunca leve. As tags antigas têm mensagem vazia e a 7.15.19 tem o próprio número; use o número.

A tag não é decorativa: config/environment.rb:12 deriva APP_VERSION de git describe --tag --always em tempo de execução, então é ela que aparece no rodapé da aplicação.

5. Label e issues

gh label create 7.15.21 --color 0e8a16 --repo gems-uff/sapos
gh issue edit <N> --add-label 7.15.21
gh issue close <N> --reason completed

• Cor 0e8a16 para todo label de versão — é o que dá o verde uniforme na lista.
• Rotular e fechar são decisões separadas. Uma issue entregue em parte leva o label e continua aberta (a #621 tem 7.15.19 e segue aberta). Só feche o que a versão de fato encerra.
• Fechamento é completed, sem comentário de encerramento — é o padrão do repositório.

6. Release no GitHub

gh api repos/gems-uff/sapos/releases \
  -f tag_name=7.15.21 \
  -f name='' \
  -f body='Issues atendidas: https://github.com/gems-uff/sapos/issues?q=label%3A7.15.21' \
  -F draft=false -F prerelease=false

O nome é vazio — o GitHub exibe a tag. Por isso a chamada é pela API: o gh release create quer título.

O corpo aponta para a consulta do label, e não para uma lista escrita à mão, que envelhece. Repare no %3A — é o : de label:7.15.21 codificado.

Quando a versão traz trabalho sem issue (o caso das vulnerabilidades), descreva em prosa antes do link e troque o rótulo dele:

Atualização do Rails de 7.1.6 para 7.2.3.1.

Demais issues atendidas: https://github.com/gems-uff/sapos/issues?q=label%3A7.15.21

Sem isso, a release diz "issues atendidas" sobre uma versão cuja mudança principal não está em issue nenhuma. Para vulnerabilidade, descreva a atualização (gem, de → para) sem citar CVE nem descrever o ataque.

7. Confira

gh release list --limit 3          # a nova deve aparecer como Latest
gh issue list --label 7.15.21 --state all

8. Deploy — do mantenedor

Passe a tag certa. Uma versão errada exibida em produção já foi rastreada até a tag passada no deploy, não ao Passenger. Depois de subir, confira o rodapé da aplicação.

Depois da release

• Apague o ramo lançado (GitHub e local), e pode git fetch --prune.
• Se a release fecha alerta do Dependabot, ele só re-varre o ramo padrão — o quadro de alertas leva alguns minutos para refletir o push.