Escreva uma entrada de changelog que informe o que mudou e o que fazer
Transforme release notes brutas em uma entrada de changelog que separe mudanças de ações obrigatórias do usuário e etapas de verificação. Uma atualização sintética de software mostra como tornar uma nota de versão útil para alguém que não fez a alteração.
Conteúdo verificado 2026.09.20Inclui arquivos de exemplo
Ver o sumário
A tradução foi feita com IA. Confira o código, as unidades e os valores junto com o original. A revisão por falantes nativos de cada idioma ainda não foi concluída. English
Para quem éEste guia é voltado a equipes que precisam de release notes ou changelogs de projeto que informem tanto o que mudou quanto o que os leitores devem fazer em seguida.
Preparação
Python 3.12 e um comando de terminal que inicie essa versão.
Um editor de texto capaz de salvar arquivos JSON e text files em UTF-8.
Uma pasta de trabalho em que o script possa criar uma nova pasta dentro de outputs.
É necessária apenas a biblioteca padrão do Python: json e pathlib.
01Separe a mudança da ação do leitor
Uma entrada de changelog deve responder a pelo menos três perguntas práticas: o que mudou, o que o leitor precisa fazer e como o leitor pode verificar se a atualização funcionou. Uma lista de implementation details pode estar correta e ainda deixar outro membro da equipe sem saber se alguma ação é necessária.
Este tutorial usa uma pequena release sintética com três changes. Cada change tem uma area, uma description factual e uma required action. Uma verification list separada informa ao leitor o que verificar após a atualização.
02Crie release notes sintéticas brutas
As release information a seguir são sintéticas e foram escritas especificamente para este artigo. Salve-as como release_notes.json. Elas descrevem a version 1.4.0 de uma ferramenta fictícia de exportação CSV.
json
{
"version": "1.4.0",
"date": "2026-09-20",
"changes": [
{
"area": "Export path",
"change": "Default CSV export folder changed from reports/ to outputs/reports/.",
"action": "Update scripts or shortcuts that expect reports/."
},
{
"area": "Config key",
"change": "Configuration key report_dir was renamed to output_dir.",
"action": "Rename report_dir to output_dir before the next run."
},
{
"area": "Validation",
"change": "Empty customer_id values now stop export instead of being written as blank cells.",
"action": "Fix blank customer_id values before rerunning failed exports."
}
],
"checks": [
"Confirm a test export appears under outputs/reports/.",
"Confirm the configuration uses output_dir.",
"Confirm a row with a blank customer_id stops with a validation error."
]
}
Há exatamente 3 changes, 3 required actions e 3 verification checks. Como o exemplo é sintético, esses paths, configuration names e behaviors são valores de demonstração, e não fatos sobre um produto real.
03Determine manualmente a entrada de changelog esperada
A entrada deve começar com version e date. As change descriptions devem permanecer factuais. Required actions devem usar instructions diretas, e verification deve ficar separada para que os leitores consigam distinguir configuration work de post-update checks.
text
Version 1.4.0 - 2026-09-20
What changed
- Export path: Default CSV export folder changed from reports/ to outputs/reports/.
- Config key: Configuration key report_dir was renamed to output_dir.
- Validation: Empty customer_id values now stop export instead of being written as blank cells.
What you need to do
- Update scripts or shortcuts that expect reports/.
- Rename report_dir to output_dir before the next run.
- Fix blank customer_id values before rerunning failed exports.
Check after updating
- Confirm a test export appears under outputs/reports/.
- Confirm the configuration uses output_dir.
- Confirm a row with a blank customer_id stops with a validation error.
A entrada esperada contém uma heading line, três section headings e nove bullet lines: três changes, três actions e três checks. Nenhuma action fica escondida dentro de um parágrafo que descreve o change.
04Gere e valide a entrada de changelog
Salve o script a seguir como useful_changelog.py. Ele valida o JSON sintético, cria o changelog text, verifica as section e bullet counts esperadas e grava o resultado em uma nova output folder. O arquivo JSON original é apenas lido.
python
import json
from pathlib import Path
SOURCE = Path("release_notes.json")
OUTPUT_DIR = Path("outputs") / "useful_changelog_result"
OUTPUT = OUTPUT_DIR / "CHANGELOG_ENTRY.txt"
def require_text(value, name):
if not isinstance(value, str) or not value.strip():
raise ValueError(f"{name} must be a non-empty string.")
return value.strip()
def main() -> None:
if not SOURCE.is_file():
raise FileNotFoundError(f"Source file not found: {SOURCE}")
if OUTPUT_DIR.exists():
raise FileExistsError(f"Output folder already exists: {OUTPUT_DIR}")
with SOURCE.open("r", encoding="utf-8") as stream:
data = json.load(stream)
version = require_text(data.get("version"), "version")
date = require_text(data.get("date"), "date")
changes = data.get("changes")
checks = data.get("checks")
if not isinstance(changes, list) or not changes:
raise ValueError("changes must be a non-empty list.")
if not isinstance(checks, list) or not checks:
raise ValueError("checks must be a non-empty list.")
change_lines = []
action_lines = []
for index, item in enumerate(changes, start=1):
if not isinstance(item, dict):
raise ValueError(f"Change {index} must be an object.")
area = require_text(item.get("area"), f"change {index} area")
change = require_text(item.get("change"), f"change {index} description")
action = require_text(item.get("action"), f"change {index} action")
change_lines.append(f"- {area}: {change}")
action_lines.append(f"- {action}")
check_lines = [f"- {require_text(value, 'check')}" for value in checks]
lines = [
f"Version {version} - {date}",
"",
"What changed",
*change_lines,
"",
"What you need to do",
*action_lines,
"",
"Check after updating",
*check_lines,
]
text = "\n".join(lines) + "\n"
if text.count("\nWhat changed\n") != 1:
raise RuntimeError("Missing What changed section.")
if text.count("\nWhat you need to do\n") != 1:
raise RuntimeError("Missing action section.")
if text.count("\nCheck after updating\n") != 1:
raise RuntimeError("Missing verification section.")
bullet_count = sum(line.startswith("- ") for line in lines)
expected_bullets = len(changes) * 2 + len(checks)
if bullet_count != expected_bullets:
raise RuntimeError("Unexpected bullet count.")
OUTPUT_DIR.parent.mkdir(parents=True, exist_ok=True)
OUTPUT_DIR.mkdir()
with OUTPUT.open("x", encoding="utf-8") as stream:
stream.write(text)
print(f"Changes: {len(changes)}.")
print(f"Required actions: {len(action_lines)}.")
print(f"Verification checks: {len(checks)}.")
print(f"Total bullets: {bullet_count}.")
print(f"Output: {OUTPUT.as_posix()}")
if __name__ == "__main__":
main()
05Verifique o resultado esperado
Para esta release sintética, o script deve informar três changes, três required actions, três verification checks e nove bullet lines. A saída esperada do console abaixo foi derivada manualmente e não é um execution log.
Confirme que cada change aparece uma vez em What changed.
Confirme que todo change tem uma instruction correspondente em What you need to do.
Confirme que verification steps estão separados das required actions.
Confirme que paths e configuration names foram copiados exatamente das synthetic source notes.
Execute o script novamente sem alterar OUTPUT_DIR. Ele deve parar com FileExistsError em vez de substituir a entrada anterior.
06Reconheça entradas de changelog tecnicamente corretas, mas pouco úteis
Texto fraco de changelog
O que está faltando
Updated export logic
Os leitores não sabem qual behavior mudou nem se precisam agir.
Fixed configuration
A key afetada e o replacement necessário não são identificados.
Improved validation
A nova failure condition e o efeito sobre os users não estão claros.
Various bug fixes
Não há informações sobre impact, scope ou required checks.
Please update accordingly
A action é vaga demais para ser executada ou verificada.
Evite fazer o leitor reconstruir a mudança a partir de issue trackers, commits ou chat history. Se uma atualização altera path, key, command, file format ou required input, informe diretamente o old e o new behavior.
07Mantenha o changelog limitado às consequências visíveis para o usuário
Uma entrada de changelog não substitui technical documentation, migration instructions, test evidence ou version control history. Changes complexos podem precisar de links para esses materiais, mas o changelog ainda deve resumir a consequence e a immediate action.
Nem todo internal refactor precisa de uma entrada de changelog. Se behavior, interfaces, dependencies, required inputs, outputs, configuration ou workflow não mudarem para o leitor, implementation notes detalhadas podem pertencer a outro lugar.
Para releases maiores, agrupe changes relacionados por area e diferencie required actions de optional recommendations. Preserve entradas antigas do changelog em vez de reescrever o histórico, a menos que esteja corrigindo um documented error e consiga registrar essa correction claramente.
Foram contados manualmente 3 synthetic changes, 3 corresponding required actions e 3 verification checks.
Foi derivada manualmente a entrada de changelog esperada com três named sections.
Foi calculado o total esperado de 9 bullet lines: 3 changes + 3 actions + 3 checks.
Foi verificado que os synthetic old and new export paths são reports/ e outputs/reports/ e que os configuration names são report_dir e output_dir.
O script foi inspecionado quanto a required text validation, section checks, bullet-count validation, output collision protection e preservação do source JSON.
A saída esperada do console foi derivada manualmente.
Limites da verificação
O código não foi executado pelo autor desta resposta; nenhum changelog file foi criado.
A version, os paths, as configuration keys e o validation behavior são exemplos sintéticos e não descrevem um produto real.
O script valida a structure, mas não consegue determinar se uma change description escrita por uma pessoa está completa ou correta.
As URLs da documentação oficial foram fornecidas com base em locais de documentação conhecidos, mas não foram verificadas ao vivo.
Em vez de parar em mais um resumo da reunião, separe o trabalho acordado dos itens em aberto. Transforme notas sintéticas de reunião em uma lista com responsáveis, prazos, entregáveis e evidências de conclusão, e escreva uma solicitação para IA que ajude na mesma tarefa.
Gerencie cada artigo como uma linha e separe redação, revisão, aprovação e publicação. Abrange importação de um CSV local, listas suspensas, filter views, permissões de compartilhamento e histórico de versões, além de configurar um fluxo para atualizar manualmente os arquivos do site após a aprovação.
Defina uma convenção simples de nomes de arquivos para a equipe, teste-a em uma pasta sintética e gere um relatório de revisão sem renomear nem excluir nada. O verificador separa erros estruturais, datas inválidas e extensões não suportadas.
Transforme notas de passagem de projeto em uma lista estruturada que registre o que precisa ser transferido, quem é responsável, onde está armazenado e o que permanece sem solução. Um pequeno exemplo sintético mostra como detectar responsáveis, locais e detalhes de pendências ausentes antes da passagem.