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 no Changelog

# 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

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.

Por que manter um changelog?

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

Quem precisa de um changelog?

Pessoas precisam. Seja consumidores ou desenvolvedores, os usuários finais de softwares são seres humanos que se preocupam com o que está no software. Quando o software muda, as pessoas querem saber por que e como.

Como fazer um bom changelog?

Princípios fundamentais

Changelogs são para humanos, não máquinas.
Deve haver uma entrada para cada versão.
Alterações do mesmo tipo devem ser agrupadas.
Versões e seções devem ser vinculáveis (com links).
A versão mais recente vem em primeiro lugar.
A data de lançamento de cada versão é exibida.
Mencione se você segue o versionamento semântico.

Tipos de mudanças

Added/Adicionado para novos recursos.
Changed/Modificado para alterações em recursos existentes.
Deprecated/Obsoleto para recursos que serão removidos nas próximas versões.
Removed/Removido para recursos removidos nesta versão.
Fixed/Corrigido para qualquer correção de bug.
Security/Segurança em caso de vulnerabilidades.

Como eu posso minimizar o esforço exigido para manter um changelog?

Mantenha sempre uma seção Unreleased/Não publicado no topo para manter o controle das novas 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 a seção Unreleased/Não publicado para o número de versão e adicionar uma nova seção Unreleased/Não publicado no topo.

Os changelogs podem ser ruins?

Sim. Aqui estão algumas maneiras pelas quais eles podem ser inúteis.

Usar um registro de alterações automático

Usar um registro de alterações automático é uma má ideia: eles estão cheios de bagunça. Coisas como solicitação de mesclagem, envio com títulos estranhos, alterações de documentação, etc.

O propósito de um commit é documentar a etapa na evolução do código fonte. Alguns projetos limpam os commits, outros não.

O propósito de uma entrada de changelog é documentar as diferenças notáveis, muitas vezes de múltiplos commits, para comunicar de forma clara os usuários.

Ignorando depreciações

Quando pessoas atualizam de uma versão para outra, deve ficar muitíssimo claro quando algo vai quebrar. Deve ser possível atualizar para uma versão com depreciações listadas, remova o que é obsoleto, depois atualize para a versão onde as depreciações se tornam remoções.

Se você não fizer mais nada, liste no seu changelog as depreciações, remoções e quaisquer mudanças que gerem falhas.

Datas confusas

Os formatos regionais de data variam em todo o mundo e muitas vezes é difícil encontrar um formato de data amigável que seja intuitivo para todos. A vantagem das datas formatadas como 2017-07-17 é que elas seguem a ordem da maior para a menor unidade de tempo: ano, mês e dia. Este formato também não se confunde de maneira ambígua com outros formatos de data, ao contrário de alguns formatos regionais que alteram a posição dos números do mês e dia. Esses motivos, e o fato de ser um formato de data suportado pela norma ISO são as razões para ele ser o formato de data recomendado para as entradas do changelog.

Perguntas frequentes

Existe um padrão para o formato do changelog?

Na verdade não. Existe o guia de estilo de changelog do GNU ou o "guia" de dois parágrafos do GNU NEWS. Ambos são inadequados ou insuficientes.

Este projeto pretende ser uma convenção de changelog melhor. Ele vem de observar e coletar as boas práticas em código aberto da comunidade.

Críticas saudáveis, discussões e sugestões de melhorias são bem-vindas.

Qual nome o arquivo changelog deve ter?

Chame-o CHANGELOG.md. Alguns projetos usam HISTORY, NEWS ou RELEASES.

Embora seja fácil pensar que o nome do seu arquivo changelog não importa muito, por que tornar mais difícil para seus usuários finais encontrarem consistentemente mudanças notáveis?

E sobre o GitHub Releases?

É uma grande iniciativa. Lançamentos podem ser usados para converter simples marcadores do git (por exemplo, um marcador chamado v1.0.0) em notas de versão ricas, adicionando manualmente notas de versão ou pode puxar as mensagens anotadas no marcador do git e transformá-las em notas.

GitHub Releases cria um changelog não portátil que só pode ser exibido para usuários no contexto do GitHub. É possível fazê-los parecer muito como o formato Keep a Changelog, mas tende a ser um pouco mais complicado.

A versão atual do GitHub Releases não é facilmente descoberta por usuários finais, ao contrário dos arquivos maiúsculos típicos (README, CONTRIBUTING, etc.). Outro problema de menor magnitude é que a interface atualmente não oferece links para confirmar alterações entre cada lançamento.

Os changelogs podem ser criados automaticamente?

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

Vandamme é um gem Ruby criado pelo time Gemnasium e que analisa muitas (mas não todas) alterações de projetos de código aberto.

E o lançamentos removidos?

Lançamentos removidos são versões que foram retiradas por causa de problemas sérios ou falhas de segurança. Muitas vezes essas versões nem aparecem no histórico de alterações. Eles deviam. É assim que você deve exibi-los:

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

O marcador [REMOVIDO] está em caixa alta por uma razão. É importante que as pessoas o percebam. Já que está entre colchetes, também fica mais fácil de ser analisado programaticamente.

Você deve reescrever um changelog?

Claro. Sempre existe razão para melhorar um changelog. Eu regularmente solicito alterações em projetos de código livre que possuem changelogs não mantidos para adicionar lançamentos que não estão presentes nestes.

Também é possível que você descubra que você esqueceu de abordar uma mudança abrupta nas notas para uma versão. Obviamente é importante que você atualize seu changelog neste caso.

Como eu posso ajudar?

Esse documento não é uma verdade absoluta; É minha opinião cuidadosamente considerada, juntamente com informações e exemplos que eu reuni.

Isso porque o que eu quero é que nossa comunidade chegue a um consenso. Eu acredito que a discussão é tão importante quanto o resultado final.

Então, por favor contribua.

Discussões

Eu fui no The Changelog podcast para falar sobre por que os mantenedores e contribuidores devem se preocupar com os changelogs, e também sobre as motivações por trás desse projeto.