There is a newer version available: Pyccкий 1.0.0

Ведите CHANGELOG

Не позволяйте друзьям сливать логи гита в CHANGELOG™

Version 0.3.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.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]
### Changed
- Update and improvement of Polish translation from [@m-aciek](https://github.com/m-aciek).

## [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 [@karalamalar](https://github.com/karalamalar).
- French translation from [@zapashcanon](https://github.com/zapashcanon).
- Brazilian Portugese translation from [@Webysther](https://github.com/Webysther).
- Polish translation from [@amielucha](https://github.com/amielucha).
- 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).

### 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?"












Для чего нужен лог изменений?

Чтобы пользователи и контрибьюторы могли с меньшими усилиями точно определить, какие значимые изменения были сделаны в каждом релизе (или версии) проекта.

Почему я вообще должен думать об этом?

Потому, что инструменты программирования делаются для людей. Если вам пофигу, зачем вы вообще занимаетесь программным обеспечением с открытым исходным кодом? У вас обязательно в голове должен быть центр «не пофигу» :)

Я беседовал с Адамом Стаковиаком и с Джеродом Санто в подкасте The Changelog (в тему название, правда?) о том почему авторам программного обеспечения с открытым исходным кодом и их коллегам должно быть не пофигу, и о моих мотивах в создании этого проекта. Послушайте, если у вас есть время (1:06).

Что должно быть в хорошем логе изменений?

Я рад, что вы спросили.

Хороший лог изменений придерживается этих приниципов:

Как минимизировать время, необходимое для ведения лога изменений?

Всегда ведите секцию Unreleased в начале файла, чтобы держать в ней не выпущенные изменения.

Это нужно для двух вещей:

Что заставляет плакать единорогов?

Хорошо… давайте разберёмся.

Существуют и другие. Помогите мне собрать слёзы единорогов, открыв тикет или пулл-реквест.

Существует стандарт формата лога изменений?

К сожалению, нет. Спокойней. Я знаю, что вы яростно бросились на поиски ссылки на GNU-руководства по стилю лога изменений, или на поиски файла «guideline» с парой параграфов в GNU NEWS. GNU-руководство по стилю неплохо для начала, но оно наивно. В наивности нет ничего плохого, но когда людям нужно руководство, она редко бывает полезна. Особенно, когда приходиться сталкиваться со множеством краевых случаев.

Этот проект содержит информацию, которая, я надеюсь, станет соглашением получше о ведении файлов CHANGELOG для всех проектов с открытым исходным кодом. Может ли сообщество учиться на своих ошибках, а не просто действовать согласно десяти записям, которые были написаны много лет назал, и, якобы, без одной ошибки? Хорошо. Поэтому, пожалуйста, посмотрите вокруг, и помните, что обсуждения и предложения по улучшению приветствуются!

Как можно назвать файл лога изменений?

Ну, если вы не не можете ответить на этот вопрос, глядя на пример выше, CHANGELOG.md пока наилучший вариант.

Некоторые проекты используют HISTORY.txt, HISTORY.md, History.md, NEWS.txt, NEWS.md, News.txt, RELEASES.txt, RELEASE.md, releases.md, и так далее.

Это непорядок. Все эти имена только усложняют поиск нужного файла.

Почему люди не могут использовать просто дифф команды git log?

Потому, что диффы логов по своей природе содержат слишком много «шума». С их помощью невозможно сделать подходящий лог изменений даже в гипотетическом проекте, который делается идеальными программистами, которые никогда не делают опечаток, никогда не забывают коммитить новые файлы, никогда не пропускают ни одну часть рефакторинга. Назначение коммита в том, чтобы задокументировать один атомарный шаг в процессе развития кода от одного состояния к другому. Назначение лога изменений – документировать значимые различия между этими состояниями.

Как отличаются хорошие комментарии к коду и сам код, также отличаются друг от друга и лог изменений с логом коммитов: первые отвечают на вопрос почему, а вторые на вопрос как.

Могут ли логи изменений быть автоматически распарсены?

Это сложно из-за того, что люди следуют сильно отличающимся форматам и соглашениям о именах файлов.

Гем для Руби Vandamme, который создали в команде Gemnasium, парсит многие (но не все) логи изменений проектов с открытым исходным кодом.

Почему вы пишите то «CHANGELOG», то «лог изменений»?

«CHANGELOG» – это имя файла. Оно несколько крикливо, но это историческое соглашение, которому следуют многие проекты с открытым исходным кодом. В качестве примеров подобных файлов можно привести README, LICENSE, и CONTRIBUTING.

Верхний регистр в имени файла (который в старых операционных системах заставляет эти файлы находиться наверху списков) используется для привлечения внимания. Так как в этих файлах содержится важная метаинформация о проекте, они могут быть полезны любому использующему или дорабатывющему проект, также как бейджи проектов с открытым исходным кодом.

Когда я упоминаю «лог изменений», я говорою о назначении этого файла: об учёте изменений.

Как насчёт yanked-релизов?

Yanked-релизы – это версии, которые изымаются из обращения из-за серьёзного бага или проблемы безопасности в них. Часто такие версии даже не упоминаются в логах изменений. А должны. И вот как вам следует их упоминать:

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

Тег [YANKED] такой «громкий» не просто так. Очень важно, чтобы люди его заметили. А из-за того, что он окружён скобками, его легче определить программно.

Стоит ли переписывать лог изменений?

Конечно. Всегда есть причины для улучшения лога изменений. Я регулярно открываю пулл-реквесты в проекты с открытым исходным кодом с неподдерживаемыми логами изменений для добавления недостающих релизов.

Также вы можете обнаружить что вы забыли адресовать критичное изменение в описании версии. В этом случае очевидно, что нужно обновить лог изменений.

Как я могу помочь?

Этот документ не истина в последней инстанции; это моё тщательно сформулированное мнение вместе с информацией и примерами, которые я собрал. Хотя я предоставил настоящий CHANGELOG из GitHub-репозитария, я специально избегал цели создать стандарт или чёткий список правил (как это делает, например, SemVer.org).

Я сделал это потому, что хочу, чтобы наше сообщество достигло консенсуса. Я верю, что дискуссия также важна, как и её результат.

Так что, пожалуйста, участвуйте.