Release
O towncrier, a subida de versão como ato do autor, e por que publicar é mergear.
Esta página cobre como uma mudança vira um lançamento: o fragmento de changelog
que todo pull request carrega, o towncrier montando os fragmentos, e a subida
de versão como ato deliberado do autor em vez de algo calculado.
Antes de começar
Um branch com a mudança pronta e o portão local verde. Publicar é mergear: um
merge em main que move a versão em pyproject.toml cria a tag e dispara o
lançamento, e um merge que não a move não publica nada.
Os passos
Deixar um fragmento por pull request
Todo pull request que muda comportamento deixa um fragmento em
changelog.d/, nomeado<issue>.<tipo>.md, onde o tipo é um debreaking,added,changed,deprecated,removed,fixedousecurity.echo "O que mudou, em uma frase." > changelog.d/142.added.mdSubir a versão no nível que os fragmentos exigem
O nível não é julgamento. Ele é lido dos tipos dos fragmentos que estão em
changelog.d/.uv version --bump minorMontar o changelog
Entradas em
CHANGELOG.mdnunca são escritas à mão. O número da issue vem de graça no nome do arquivo, e é isso que transforma o changelog num índice navegável de volta para as decisões.uv run towncrier build --version "$(uv version --short)"
Verificação
Confira a versão que o pull request leva, antes de abri-lo:
uv version
O número impresso tem de estar acima do que a main publica. Depois do merge e do
deploy, confirme que o PyPI serve a versão nova:
uvx overpower@latest --version
A saída é a mesma versão que o uv version mostrou. Enquanto o PyPI ainda não
propagou, @latest continua devolvendo a anterior.
O release-ready é uma conferência obrigatória ao lado do gate, e recusa um
pull request que muda o que aterrissa na wheel sem também mover a versão. A
mensagem de falha imprime o nível que ele calculou e os dois comandos a rodar; a
tabela de níveis está em o release-ready.
uvx overpower@latest guarda o que já baixou. Se a versão nova não aparecer,
force a busca em vez de concluir que o deploy falhou.