There is a newer version available: Português do Brasil 1.1.0

Mantenha um CHANGELOG

Não deixe seus amigos despejarem logs de commits em CHANGELOGs

Version 0.3.0

O que é um changelog?

Um changelog é um arquivo que contém uma lista selecionada, ordenada cronologicamente, de mudanças significativas para cada versão de um projeto open source.

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

### Added

- v1.1 Brazilian Portuguese translation.
- v1.1 German Translation
- v1.1 Spanish translation.
- v1.1 Italian translation.
- v1.1 Polish translation.
- v1.1 Ukrainian translation.

### Changed

- Use frontmatter title & description in each language version template
- Replace broken OpenGraph image with an appropriately-sized Keep a Changelog 
  image that will render properly (although in English for all languages)
- Fix OpenGraph title & description for all languages so the title and 
description when links are shared are language-appropriate

### Removed

- Trademark sign previously shown after the project description in version 
0.3.0

## [1.1.1] - 2023-03-05

### Added

- Arabic translation (#444).
- v1.1 French translation.
- v1.1 Dutch translation (#371).
- v1.1 Russian translation (#410).
- v1.1 Japanese translation (#363).
- v1.1 Norwegian Bokmål translation (#383).
- v1.1 "Inconsistent Changes" Turkish translation (#347).
- Default to most recent versions available for each languages.
- Display count of available translations (26 to date!).
- Centralize all links into `/data/links.json` so they can be updated easily.

### Fixed

- Improve French translation (#377).
- Improve id-ID translation (#416).
- Improve Persian translation (#457).
- Improve Russian translation (#408).
- Improve Swedish title (#419).
- Improve zh-CN translation (#359).
- Improve French translation (#357).
- Improve zh-TW translation (#360, #355).
- Improve Spanish (es-ES) transltion (#362).
- Foldout menu in Dutch translation (#371).
- Missing periods at the end of each change (#451).
- Fix missing logo in 1.1 pages.
- Display notice when translation isn't for most recent version.
- Various broken links, page versions, and indentations.

### Changed

- Upgrade dependencies: Ruby 3.2.1, Middleman, etc.

### Removed

- Unused normalize.css file.
- Identical links assigned in each translation file.
- Duplicate index file for the english version.

## [1.1.0] - 2019-02-15

### Added

- Danish translation (#297).
- Georgian translation from (#337).
- Changelog inconsistency section in Bad Practices.

### Fixed

- Italian translation (#332).
- Indonesian translation (#336).

## [1.0.0] - 2017-06-20

### Added

- New visual identity by [@tylerfortune8](https://github.com/tylerfortune8).
- Version navigation.
- Links to latest released version in previous versions.
- "Why keep a changelog?" section.
- "Who needs a changelog?" section.
- "How do I make a changelog?" section.
- "Frequently Asked Questions" section.
- New "Guiding Principles" sub-section to "How do I make a changelog?".
- Simplified and Traditional Chinese translations from [@tianshuo](https://github.com/tianshuo).
- German translation from [@mpbzh](https://github.com/mpbzh) & [@Art4](https://github.com/Art4).
- Italian translation from [@azkidenz](https://github.com/azkidenz).
- Swedish translation from [@magol](https://github.com/magol).
- Turkish translation from [@emreerkan](https://github.com/emreerkan).
- French translation from [@zapashcanon](https://github.com/zapashcanon).
- Brazilian Portuguese translation from [@Webysther](https://github.com/Webysther).
- Polish translation from [@amielucha](https://github.com/amielucha) & [@m-aciek](https://github.com/m-aciek).
- Russian translation from [@aishek](https://github.com/aishek).
- Czech translation from [@h4vry](https://github.com/h4vry).
- Slovak translation from [@jkostolansky](https://github.com/jkostolansky).
- Korean translation from [@pierceh89](https://github.com/pierceh89).
- Croatian translation from [@porx](https://github.com/porx).
- Persian translation from [@Hameds](https://github.com/Hameds).
- Ukrainian translation from [@osadchyi-s](https://github.com/osadchyi-s).

### Changed

- Start using "changelog" over "change log" since it's the common usage.
- Start versioning based on the current English version at 0.3.0 to help
  translation authors keep things up-to-date.
- Rewrite "What makes unicorns cry?" section.
- Rewrite "Ignoring Deprecations" sub-section to clarify the ideal
  scenario.
- Improve "Commit log diffs" sub-section to further argument against
  them.
- Merge "Why can’t people just use a git log diff?" with "Commit log
  diffs".
- Fix typos in Simplified Chinese and Traditional Chinese translations.
- Fix typos in Brazilian Portuguese translation.
- Fix typos in Turkish translation.
- Fix typos in Czech translation.
- Fix typos in Swedish translation.
- Improve phrasing in French translation.
- Fix phrasing and spelling in German translation.

### Removed

- Section about "changelog" vs "CHANGELOG".

## [0.3.0] - 2015-12-03

### Added

- RU translation from [@aishek](https://github.com/aishek).
- pt-BR translation from [@tallesl](https://github.com/tallesl).
- es-ES translation from [@ZeliosAriex](https://github.com/ZeliosAriex).

## [0.2.0] - 2015-10-06

### Changed

- Remove exclusionary mentions of "open source" since this project can
  benefit both "open" and "closed" source projects equally.

## [0.1.0] - 2015-10-06

### Added

- Answer "Should you ever rewrite a change log?".

### Changed

- Improve argument against commit logs.
- Start following [SemVer](https://semver.org) properly.

## [0.0.8] - 2015-02-17

### Changed

- Update year to match in every README example.
- Reluctantly stop making fun of Brits only, since most of the world
  writes dates in a strange way.

### Fixed

- Fix typos in recent README changes.
- Update outdated unreleased diff link.

## [0.0.7] - 2015-02-16

### Added

- Link, and make it obvious that date format is ISO 8601.

### Changed

- Clarified the section on "Is there a standard change log format?".

### Fixed

- Fix Markdown links to tag comparison URL with footnote-style links.

## [0.0.6] - 2014-12-12

### Added

- README section on "yanked" releases.

## [0.0.5] - 2014-08-09

### Added

- Markdown links to version tags on release headings.
- Unreleased section to gather unreleased changes and encourage note
  keeping prior to releases.

## [0.0.4] - 2014-08-09

### Added

- Better explanation of the difference between the file ("CHANGELOG")
  and its function "the change log".

### Changed

- Refer to a "change log" instead of a "CHANGELOG" throughout the site
  to differentiate between the file and the purpose of the file — the
  logging of changes.

### Removed

- Remove empty sections from CHANGELOG, they occupy too much space and
  create too much noise in the file. People will have to assume that the
  missing sections were intentionally left out because they contained no
  notable changes.

## [0.0.3] - 2014-08-09

### Added

- "Why should I care?" section mentioning The Changelog podcast.

## [0.0.2] - 2014-07-10

### Added

- Explanation of the recommended reverse chronological release ordering.

## [0.0.1] - 2014-05-31

### Added

- This CHANGELOG file to hopefully serve as an evolving example of a
  standardized open source project CHANGELOG.
- CNAME file to enable GitHub Pages custom domain.
- README now contains answers to common questions about CHANGELOGs.
- Good examples and basic guidelines, including proper date formatting.
- Counter-examples: "What makes unicorns cry?".

[unreleased]: https://github.com/olivierlacan/keep-a-changelog/compare/v1.1.1...HEAD
[1.1.1]: https://github.com/olivierlacan/keep-a-changelog/compare/v1.1.0...v1.1.1
[1.1.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v1.0.0...v1.1.0
[1.0.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.3.0...v1.0.0
[0.3.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.2.0...v0.3.0
[0.2.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.1.0...v0.2.0
[0.1.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.8...v0.1.0
[0.0.8]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.7...v0.0.8
[0.0.7]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.6...v0.0.7
[0.0.6]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.5...v0.0.6
[0.0.5]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.4...v0.0.5
[0.0.4]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.3...v0.0.4
[0.0.3]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.2...v0.0.3
[0.0.2]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.1...v0.0.2
[0.0.1]: https://github.com/olivierlacan/keep-a-changelog/releases/tag/v0.0.1

Para que serve um changelog?

Para facilitar que usuários e contribuidores vejam precisamente quais mudanças significativas foram realizadas entre cada versão publicada.

Por que eu deveria me importar?

Porque softwares são feitos para pessoas. Se você não liga, por que está contribuindo com projetos open source? Certamente deve haver um fundo de carinho em algum lugar desse seu amável cerebrinho.

Eu conversei com Adam Stacoviak e Jerod Santo no podcast do The Changelog (faz sentido, hein?) sobre por que mantenedores e contribuidores open source devem se importar e as motivações por trás desse projeto. Se você tem tempo (1:06), é um bom programa.

O que faz um changelog ser bom?

Que bom que perguntou.

Um bom changelog se atém a esses princípios:

É feito para seres humanos, não máquinas, então legibilidade é crucial.
É fácil de referenciar (linkar) qualquer seção (por isso Markdown ao invés de puro texto).
Uma subseção por versão.
Lista as versões publicadas em ordem cronológica decrescente (mais novo em cima).
Usa todas as datas no formato AAAA-MM-DD. (Exemplo: 2012-06-02 para 2 de Junho de 2012.) É internacional, sensato, e independente de língua.
Menciona explicitamente se o projeto segue o Versionamento Semântico.
Cada versão deve:
- Listar sua data de publicação no formato acima.
- Agrupar mudanças descrevendo seus impactos no projeto, como segue:
- Added/Adicionado para novas funcionalidades.
- Changed/Modificado para mudanças em funcionalidades existentes.
- Deprecated/Obsoleto para funcionalidades estáveis que foram removidas das próximas versões.
- Removed/Removido para funcionalidades removidas desta versão.
- Fixed/Consertado para qualquer correção de bug.
- Security/Segurança para incentivar usuários a atualizarem em caso de vulnerabilidades.

Como eu posso minimizar o esforço exigido?

Mantenha sempre uma seção "Unreleased"`"A publicar"` no topo para manter o controle de quaisquer mudanças.

Isso serve a dois propósitos:

As pessoas podem ver quais mudanças elas podem esperar em publicações futuras.
No momento da publicação, você apenas tem de mudar o "Unreleased"`"A publicar"para o número de versão e adicionar um novo cabeçalho"Unreleased"\"A publicar"` no topo.

O que faz os unicórnios chorarem?

Tudo bem... vamos lá.

Despejar logs de commits. Simplesmente não faça isso, você não está ajudando ninguém.
Não dar ênfase nas obsolências. Quando as pessoas atualizam de uma versão para outra, deve ser incrivelmente claro quando algo irá parar de funcionar.
Datas em formatos específicos de uma região. Nos Estados Unidos, as pessoas colocam o mês primeiro ("06-02-2012" para 2 de Junho de 2012, o que não faz sentido), enquanto muitos no resto do mundo escrevem em aspecto robótico "2 Junho 2012", e mesmo assim leem de forma diferente. "2012-06-02" funciona de maneira lógica do maior para o menor, não se confunde de maneira ambígua com outros formatos, e é um padrão ISO. Portanto, é o formato recomendado para changelogs.

Tem mais. Ajude-me a coletar essas lágrimas de unicórnio abrindo uma issue ou um pull request.

Existe um padrão de formato de changelog?

Infelizmente, não. Calma. Eu sei que você está buscando furiosamente aquele link do guia GNU de estilo de changelog, ou o arquivo "guideline" de dois paragráfos do GNU NEWS. O estilo GNU é um bom começo mas, infelizmente, é ingênuo. Não há nada de errado em ser ingênuo mas, quando as pessoas precisam de orientação, raramente ajuda. Especialmente quando existem muitas situações excepcionais para lidar.

Este projeto contém o que eu espero se tornar um melhor padrão de arquivo CHANGELOG para todos os projetos open source. Eu não acredito que o status quo seja bom o suficiente, e acho que, como uma comunidade, nós podemos encontrar novas convenções se tentarmos extrair boas práticas de projetos de software reais. Por favor, dê uma olhada e lembre-se de que discussões e sugestões de melhorias são bem-vindas!

Qual deve ser o nome do arquivo changelog?

Bom, se você não notou no exemplo acima, CHANGELOG.md é a melhor convenção até agora.

Alguns outros projetos também utilizam HISTORY.txt, HISTORY.md, History.md, NEWS.txt, NEWS.md, News.txt, RELEASES.txt, RELEASE.md, releases.md, etc.

É uma bagunça. Todos esses nomes só dificultam encontrar o changelog.

Por que as pessoas não podem simplesmente utilizar `git log`?

Porque os logs do Git são cheios de ruído — por natureza. Eles não serviriam como um changelog adequado mesmo em um projeto hipotético executado por humanos perfeitos, que nunca erram uma letra, nunca esquecem de commitar arquivos, nunca cometem deslizes em uma refatoração. O propósito de um commit é documentar um passo atômico no processo pelo qual o código evolui de um estado a outro. O propósito de um changelog é documentar as diferenças relevantes entre esses estados.

A mesma diferença que existe entre bons comentários e o código em si existe entre o changelog e o commit log: um descreve o porquê, o outro descreve o como.

Podem os changelogs ser automaticamente interpretados?

É difícil, porque as pessoas seguem formatos e nomes de arquivos radicalmente diferentes.

Vandamme é uma gem criada pelo time Gemnasium que interpreta muitos (mas não todos) changelogs de projetos open source.

Por que você alterna entre as grafias "CHANGELOG" e "changelog"?

"CHANGELOG" é o nome do arquivo em si. É um pouco chamativo mas é uma convenção histórica seguida por muitos projetos open source. Outros exemplos similares de arquivo incluem README, LICENSE, e CONTRIBUTING.

O nome em letras maiúsculas (o que em sistemas operacionais antigos faziam estes arquivos ficarem no topo da lista) é utilizado para chamar atenção. Por conterem importantes metadados do projeto, changelogs são úteis a qualquer um que pretenda utilizar ou contribuir com o projeto, da maneira equivalente às badges de projetos open source.

Quando eu me refiro a "changelog", eu estou falando sobre a função desse arquivo: listar mudanças.

E sobre as publicações removidas?

Publicações removidas são versões que tiveram que ser removidas devido a um sério bug ou problema de segurança. Com frequência essas versões sequer aparecem em changelogs. Deveriam. É assim que você deve exibi-las:

## [0.0.5] - 2014-12-13 [YANKED]

A tag [YANKED]/[REMOVIDA] é chamativa por uma razão. É importante que as pessoas a notem. Além disso, já que é cercada por colchetes, é mais fácil detectá-la programaticamente.

Devemos alterar o changelog em alguma circunstância?

Claro. Sempre existem bons motivos para melhorar um changelog. Eu regularmente abro pull requests para adicionar versões faltantes em projetos open source com changelogs abandonados.

Também é possível que você perceba que se esqueceu de registrar mudanças importantes nas notas de uma versão. É obviamente importante que você atualize seu changelog nesse caso.

Como eu posso contribuir?

Este documento não é a verdade; é minha cuidadosa opinião, junto com as informações e exemplos que reuni. Embora eu tenha providenciado um CHANGELOG no repositório no GitHub, eu não criei de propósito uma lista clara de regras a serem seguidas (como o SemVer.org faz, por exemplo).

Fiz isso porque eu gostaria que nossa comunidade chegasse a um consenso. Eu acredito que a discussão é tão importante quanto o resultado final.

Então, por favor, entre em campo.