Keep a Changelog

Laat je vrienden geen git logs in changelogs dumpen.

Versie 1.0.0
# 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

Wat is een changelog?

Een changelog is een bestand met een zorgvuldig samengestelde, chronologische lijst van noemenswaardige aanpassingen voor elke versie van een project.

Waarom een changelog bijhouden?

Om het makkelijker te maken voor gebruikers en programmeurs om precies te zien welke noemenswaardige aanpassingen er gedaan zijn tussen elke release (of versie) van het project.

Wie heeft een changelog nodig?

Mensen hebben het nodig. Of het nu consumenten of ontwikkelaars zijn, eindgebruikers van software zijn mensen die er om geven wat er in de software zit die ze gebruiken. Als de software verandert, wil men weten wat en hoe.

Hoe maak ik een goed changelog?

Richtlijnen

  • Changelogs zijn voor mensen, niet voor machines.
  • Er zou een vermelding moeten zijn voor elke versie.
  • Aanpassingen van het zelfde type moeten gegroepeerd worden.
  • Versies en secties zouden linkbaar moeten zijn.
  • De laatste versie staat bovenaan.
  • De release datum van elke versie word weergegeven.
  • Geef aan of je Semantic Versioning gebruikt.

Types of changes

  • Added voor nieuwe functionaliteit.
  • Changed voor aanpassingen aan bestaande functionaliteit.
  • Deprecated voor functionaliteit die binnenkort komt te vervallen.
  • Removed voor functionaliteit die vanaf nu vervallen is.
  • Fixed voor bug fixes.
  • Security voor aanpassingen met betrekking tot veiligheid.

Hoe kan ik, met zo min mogelijk moeite, een changelog bij houden?

Houd bovenin een Unreleased sectie bij met aanpassingen voor de komende release.

Dit heeft twee doelen:

  • Mensen kunnen zien wat te verwachten in de aankomende release.
  • Als je een release doet kan je eenvoudig de Unreleased sectie aanpassen naar een nieuwe release sectie.

Kan een changelog slecht zijn?

Ja. Hier een paar manieren waarop je een changelog behoorlijk onbruikbaar kan maken.

Commit log diffs

Commit log diffs gebruiken als een changelog is een slecht idee: ze staan vol met ruis. Denk bijvoorbeeld aan merge commits, commits met onduidelijke titels, documentatie aanpassingen etc.

Het doel van een commit bericht is om één enkele stap in de evolutie van de code te beschrijven.

Het doel van een changelog is om noemenswaardige aanpassingen te documenteren, vaak over meerdere commits, en om deze duidelijk naar de eindgebruiker te communiceren.

Deprecations negeren

Wanneer mensen upgraden van de ene naar de andere versie, moet het overduidelijk zijn als er iets niet meer zal werken. Het moet mogelijk zijn om te upgraden naar een versie met deprecations, vervolgens de deprecations weg te halen, en vervolgens de upgrade kunnen doen naar de versie waar de deprecations removals zijn geworden.

Geef altijd op zijn minst de deprecations, removals en changes met grote impact aan in je changelog.

Verwarrende datums

Datum notaties verschillen van land tot land, en het is vaak moeilijk om een notatie te vinden die makkelijk te lezen is en intuïtief is voor iedereen. Het voordeel van de notatie 2017-07-17 is dat het jaar, maand en dag op volgorde van grootte laat zien. Daarom, en het feit dat dit een ISO standaard is, is dit de aanbevolen datum notatie voor changelog releases.

Veel Gestelde Vragen

Is er een standaard changelog template?

Niet echt. Er is de GNU changelog style guide, en het twee paragrafen lange GNU NEWS bestand "richtlijnen". Beiden zijn niet volledig genoeg.

Dit project poogt een betere changelog standaard te creëren. Dit op basis van "good practices" uit de open source wereld.

Opbouwende kritiek, discussie en suggesties voor verbetering zijn welkom.

Wat zou de changelog bestandsnaam moeten zijn?

Noem het CHANGELOG.md. Sommige projecten gebruiken HISTORY, NEWS of RELEASES.

Je kan denken dat de bestandsnaam niet heel belangrijk is, maar waarom zou je het de eindgebruikers moeilijker maken om de changelog te vinden?

Wat denk je van GitHub Releases?

Het is een goed initiatief. Releases kan gebruikt worden om simpele git tags (bijvoorbeeld een tag met de naam v1.0.0) te veranderen in uitgebreide release notes door deze handmatig toe te voegen of door geannoteerde git tag berichten te gebruiken om release notes te genereren.

GitHub Releases maken changelog wat alleen getoond kan worden aan gebruikers binnen de context van GitHub. Het is mogelijk om deze dicht bij het format te krijgen wat wij hier promoten, maar er zal iets meer werk voor nodig zijn.

De huidige versie van GitHub releases is naar mijn mening niet echt goed vindbaar voor gebruikers, in tegenstelling tot de typische bestanden die in een naam in hoofdletters hebben (README, CONTRIBUTING, etc.). Een ander knelpunt is dat de interface geen links toestaat naar commit logs van elke release.

Kunnen changelogs automatisch geparsed worden?

Dat is lastig, mensen gebruiken immers veel verschillende formats en bestandsnamen.

Vandamme is een Ruby gem van het Gemnasium team wat de changelogs van veel (maar niet alle) open source projecten kan parsen.

Wat doen we met teruggetrokken (yanked) releases?

Teruggetrokken releases zijn versies die teruggetrokken zijn als gevolg van een serieuze bug of beveiligings probleem. Vaak zijn ze niet eens te zien in de changelogs. Dat zou wel moeten. Zo zou je een teruggetrokken release moeten tonen:

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

De [YANKED] tag is in hoofdletters voor een reden. Het is belangrijk dat mensen dit zien. Omdat het tussen blokhaken genoteerd is, is het ook makkelijker automatisch te parsen.

Mag je een changelog aanpassen/herschrijven?

Natuurlijk. Er zijn goede redenen om een changelog te verbeteren. Ik open regelmatig een pull request om missende releases toe te voegen aan open source projecten met een slecht onderhouden changelog.

Het kan ook zo zijn dat je ontdekt dat je een belangrijke aanpassing niet vermeld hebt in je changelog. Het is dan natuurlijk zaak om dit alsnog in je changelog te vermelden.

Hoe kan ik bijdragen?

Dit document is niet de waarheid; het is mijn weloverwogen mening, samen met wat informatie en voorbeelden die ik verzameld heb.

Dit heb ik gedaan omdat ik wil dat de programmeer gemeenschap een consensus bereikt. Ik denk dat de discussie net zo belangrijk is als het eindresultaat.

Dus alle hulp is welkom.

Conversaties

Ik was te gast bij The Changelog podcast om te praten over waarom een changelog belangrijk is programmeurs, en over mijn motivatie achter dit project.