Modelo de changelog: estrutura e exemplo pronto para copiar

Se você só quer um modelo pra copiar e sair usando, ele está logo abaixo. Depois dele, explico as decisões por trás da estrutura, pra você adaptar ao seu produto sem quebrar nada.

O modelo (copie e adapte)

v[versão] — [data]

• Adicionado: [funcionalidade nova, começando pelo benefício].
• Modificado: [o que mudou de comportamento e por quê].
• Corrigido: [o bug que foi resolvido, na visão do usuário].

Simples assim. Cada release vira um bloco com data/versão no topo e as mudanças agrupadas por tipo.

Um exemplo preenchido

Pra ficar concreto, veja como três releases seguidos ficariam:

v3.2.0 — 5 de julho de 2026

• Adicionado: modo escuro no painel.
• Corrigido: notificações duplicadas ao salvar um documento.

v3.1.0 — 28 de junho de 2026

• Adicionado: exportação de relatórios em CSV.
• Modificado: a exportação agora exige um token de API por segurança.

v3.0.0 — 15 de junho de 2026

• Adicionado: nova busca global, com filtros por data e por tipo.
• Removido: o antigo painel de relatórios (substituído pelo novo dashboard).

As decisões por trás da estrutura

Por que agrupar por tipo?

Porque o leitor escaneia. Quando as mudanças estão etiquetadas como Adicionado / Modificado / Corrigido, ele acha em um segundo o que interessa. Um parágrafo corrido obriga a ler tudo, e por isso não é lido.

Por que data E versão?

A versão (v3.1.0) serve pra quem acompanha releases de perto. A data serve pra todo o resto ("ah, isso mudou semana passada"). Ter os dois cobre os dois públicos. Se seu produto não usa versionamento, pode ficar só com a data.

Por que ordem cronológica invertida?

O mais recente sempre no topo. Ninguém abre um changelog pra ler o que mudou há dois anos, abre pra ver o que mudou agora.

Boas práticas que fazem diferença

• Uma mudança por linha. Se precisou de "e" no meio, provavelmente são duas.
• Comece pelo verbo do benefício. "Exporte em CSV" é melhor que "Foi adicionada a exportação em CSV".
• Rascunhe ao longo do sprint. Anote as mudanças conforme elas acontecem, não tente lembrar de tudo no dia do release.
• Publique onde o usuário está. Um changelog num arquivo do repositório não é visto por ninguém que não seja dev.

Do modelo ao changelog no ar

Copiar o modelo é o primeiro passo. O segundo é ter onde publicar de um jeito que os usuários realmente vejam. É pra isso que o Nowledge existe: você preenche esse modelo num painel e ele vira, automaticamente, um widget dentro do seu produto, uma página pública e um feed. Sem montar nada.

Dá pra começar de graça, sem cartão, e publicar a primeira novidade hoje.

Antes de escrever, vale ler também como redigir release notes que os usuários leem.