Une nouvelle version est disponible: Français 1.0.0

Tenez un CHANGELOG

Ne laissez pas vos amis utiliser les logs git comme CHANGELOGs™

Version 0.3.0

Qu’est-ce qu’un journal des modifications (change log) ?

Un journal des modifications (ou change log) est un fichier qui contient une liste triée chronologiquement des changements notables pour chaque version d’un projet

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

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

## [Unreleased]

## [1.0.0] - 2017-06-20
### Added
- New visual identity by @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.
- German translation from @mpbzh & @Art4.
- Italian translation from @azkidenz.
- Swedish translation from @magol.
- Turkish translation from @karalamalar.
- French translation from @zapashcanon.
- Brazilian Portugese translation from @aisamu.
- Polish translation from @amielucha.
- Russian translation from @aishek.

### 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 Portugese 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.
- pt-BR translation from @tallesl.
- es-ES translation from @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](http://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?"












Quel est l’intérêt d’un change log ?

Il permet aux utilisateurs et aux contributeurs de voir plus simplement les changements notables qui ont été réalisés entre chaque publication (ou version) du projet.

Pourquoi devrais-je m’en préoccuper ?

Parce que les logiciels sont pour les gens. Si vous ne vous en souciez pas, pourquoi contribuez-vous à l’open source ? Il doit sûrement y avoir un "kernel" (ha!) d’intérêt pour ça quelque part dans votre cher petit cerveau.

J’ai discuté avec Adam Stacoviak et Jerod Santo dans le podcast "The Changelog" (approprié, non ?) des raisons pour lesquelles les mainteneurs et les contributeurs devraient s’en préoccuper ; également des motivations derrière ce projet. Si vous avez le temps (1:06), l’écoute vaut le coup.

Qu’est-ce qui fait un bon change log ?

Heureux de vous entendre le demander.

Un bon change log se conforme à ces principes:

Comment puis-je minimiser le travail nécessaire ?

Ayez toujours une section "Unreleased" en haut du fichier afin de lister tous les changements pas encore publiés.

Cela rempli deux objectifs:

Quelles sont les choses qui rendent tristes les licornes ?

Très bien… parlons-en.

Il y en a d’autres. Aidez-moi à collecter ces larmes de licornes en ouvrant une issue ou une pull request.

Y a-t-il un format de change log standard ?

Malheureusement, non. Du calme. Je sais que vous êtes en train de vous précipiter afin de trouver le lien vers le guide pour change logs GNU, ou le fichier GNU NEWS "guideline" de deux paragraphes. Le guide GNU est un bon début mais il est malheureusement simpliste. Il n'y a rien de mal avec le fait d'être simpliste, mais quand les gens ont besoin d'être guidés, ce n'est que rarement utile. Spécialement quand il a beaucoup de situations et de cas particuliers à prendre en compte.

Ce projet contient ce que j'espère devenir une meilleur convention pour les fichiers CHANGELOG. Je ne pense pas que le status quo soit suffisant et je pense qu'en tant que communauté, nous pouvons arriver à de meilleures conventions si nous essayons d'extraire les meilleures pratiques depuis les vrais projets logiciels. S'il vous plaît, jetez-y un coup d'oeil et rappelez vous que les discussions et les suggestions d'améliorations sont les bienvenues!

Comment doit-être nommé le fichier de change log ?

Eh bien, si l'exemple ci-dessus ne vous suffit pas à le deviner, CHANGELOG.md est la meilleure convention à ce jour.

Certains projets utilisent aussi HISTORY.txt, HISTORY.md, History.md, NEWS.txt, NEWS.md, News.txt, RELEASES.txt, RELEASE.md, releases.md, etc.

C'est un véritable bazar. Tous ces noms ne font que rendre plus difficile son repérage par les gens.

Pourquoi les gens ne recopient pas simplement les derniers logs git ?

Parce que les logs gits sont remplis de bruit - par définition. Ils ne peuvent pas faire office de change log convenable, même dans un hypothétique projet tenu par des humains parfaits qui ne font jamais la moindre faute de frappe, n'oublient jamais de committer les nouveaux fichiers, ne manquent jamais aucune partie d'un refactoring. Le but d'un commit est de documenter une étape atomique dans le processus par lequel le code évolue d'un état à un autre. Le but d'un change log est de documenter les différences notables entre ces états.

La différence entre des bons commentaires et le code lui-même est la même que celle entre un change log et les journaux git: l'un décrit le pourquoi, l'autre le comment.

Les change logs peuvent-ils être parsés automatiquement ?

C'est difficile, parce que les gens suivent des formats et utilisent des noms de fichiers très différents.

Vandamme est une Ruby gem créée par l'équipe Gemnasium qui parse les change logs de beaucoup (mais pas tous) de projets open source.

Pourquoi cette alternance entre les graphies "CHANGELOG" et "change log" ?

"CHANGELOG" est le nom pour le fichier même. C'est un peu imposant, mais dû à une convention historique suivie par beaucoup de projets open source. Il existe d'autres fichiers similaires, par exemple : README, LICENSE, and CONTRIBUTING.

L'écriture en majuscule (qui dans les vieux systèmes d'exploitation faisait apparaître ces fichiers en haut) de ces noms de fichiers est utilisée pour attirer l'attention sur eux. Puisqu'ils font partie des méta-données importantes du projet, ils pourraient être utiles à quiconque voulant y l'utiliser ou y contribuer, tout comme les badges de projet open source.

Quand j'utilise la graphie "change log", je fais référence à la fonction de ce fichier: journaliser les changements.

Qu'en est-il des publications "yanked" ?

Les publications yanked sont des version qui ont dû être retirées du fait d'un sérieux bug ou d'un problème de sécurité. Souvent ces version n'apparaissent même pas dans les change logs. Elles devraient. Voilà comment les afficher:

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

Le tag [YANKED] n'est pas mis en avant pour rien. C'est important pour les gens de le remarquer. Puisqu'il est entouré par des crochets, c'est aussi plus facile à parser pour un programme.

Devriez-vous réécrire un change log ?

Bien sûr. Il y a toujours de bonnes raisons d'améliorer un change log. J'ouvre souvent des pull requests pour ajouter des publications manquantes sur des projets open source avec des change logs non-maintenus.

Il est aussi possible que vous découvriez que vous aviez oublié de mentionner un changement majeur dans les notes de version. Il est évidemment important que vous mettiez votre change log à jour dans ce cas.

Comment puis-je contribuer ?

Ce document n'est pas la vérité; c'est mon opinion soigneusement réfléchie, accompagnée d'informations et d'exemples que j'ai rassemblés. Bien que je fournisse un véritable CHANGELOG sur le dépôt GitHub, je n'ai volontairement pas créé de véritable publication ou de liste précise de règles à suivre (comme le fait SemVer.org, par exemple).

C'est parce que je veux que notre communauté atteigne un consensus. Je crois que la discussion est aussi importante que le résultat final.

Donc s'il vous plaît, mettez-vous y.