Ведите CHANGELOG

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

Version 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.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?"

[Unreleased]: https://github.com/olivierlacan/keep-a-changelog/compare/v1.0.0...HEAD
[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

Что такое лог изменений?

Лог изменений – это файл, который содержит поддерживаемый, хронологически упорядоченный список изменений для каждой версии проекта.

Зачем вести лог изменений?

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

Кому нужен лог изменений?

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

Как мне сделать хороший лог изменений?

Главные принципы

  • Лог изменений ведётся для людей, не для машин.
  • Для каждой версии должен быть отдельный раздел.
  • Одинаковые типы изменений должны быть сгруппированы.
  • Должна быть возможность поставить ссылку на любую версию или раздел.
  • Последняя версия должна идти в начале файла.
  • У каждой версии указана дата выпуска.
  • Уточните, следуете ли вы принципам Семантического версионирования

Типы изменений

  • Добавлено для новых функций.
  • Изменено для изменений в существующей функциональности.
  • Устарело для функций, которые скоро будут удалены.
  • Удалено для удалённых функций.
  • Исправлено для любых исправлений.
  • Безопасность в случае уязвимостей.

Как мне тратить меньше усилий на ведение лога изменений?

Ведите раздел Новое с изменениями для новой версии в начале файла.

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

  • Люди смогут видеть, каких изменений им ожидать в ближайших релизах
  • В момент релиза вы можете переместить изменения раздела Новое в раздел нового релиза.

Бывают плохие логи изменений?

Да. Вот несколько способов чтобы сделать их не такими полезными.

Диффы лога коммитов

Использование диффов лога коммитов это плохая идея: они очень шумные. Шумят мердж-коммиты, коммиты с непонятными названиями, изменения в документации и тому подобное.

Назначение коммита в том, чтобы задокументировать шаг в эволюции исходного кода. В некоторых проектах следят за историей коммитов, в некоторых нет.

Назначение же раздела в логе изменений — задокументировать ключевые различия, часто между несколькими коммитами, чтобы ясно донести их назначение до конечных пользователей.

Игнорирование устаревающих функций

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

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

Непонятные даты

В США сначала пишут месяц (06-02-2012 для 2 июня 2012), в то время как большинство людей в остальном мире пишут роботоподобное 2 июня 2012, произнося эту дата по-разному. Запись 2012-06-02 логично идёт от большего к меньшему, не пересекается с большинством других форматов дат, и является стандартом ISO. Поэтому именно такой формат рекомендуется для логов изменений.

Часто задаваемые вопросы

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

На самом деле нет. Есть стайлгайд логов изменений GNU, есть длиной-в-два-параграфа файл "guideline" GNU NEWS. Оба или неадекватны или недостаточно полны.

Цель этого проекта — стать улучшенной версией соглашения о формате логов изменений. Это приходит из-за сбора и следования хорошим практикам сообщества.

Здоровая критика, дискуссии и предложения по улучшению приветствуются.

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

Назовите его CHANGELOG.md. Некоторые проекты также используют HISTORY, NEWS или RELEASES.

Хоть и легко подумать, что имя файла лога изменений не так уж и важно, но зачем усложнять вашим конечным пользователям поиск места, где описаны все ключевые изменения?

Что насчёт функции "Релизы" на Гитхабе?

Это отличная инициатива. Релизы могут использоваться для превращения простых тегов в Git (например, тег v1.0.0) в подробные заметки к релизам с помощью их редактирования вручную, или с помощью комментариев к таким тегам.

Релизы на Гитхабе создают непереносимый лог изменений, который может быть показан пользователям только на самом Гитхабе. Возможно вести их в формате, близком к формату проекта Keep a Changelog, но это требует больших усилий.

Текущая версия Релизов на Гитхабе также возможно не так хорошо видна для конечных пользователей, в отличие от обычных файлов с именами в верхнем регистре (README, CONTRIBUTING и так далее). Другая небольшая проблема заключается в том, что интерфейс не предлагает ссылок на логи коммитов между релизами.

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

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

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

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

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

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

Тег [YANKED] так бросается в глаза специально. Очень важно, чтобы люди его заметили. Так как он обрамлён квадратными скобками, его также проще распарсить программно.

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

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

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

Как я могу помочь вашему проекту?

Этот документ не истина в последней инстанции; это моё тщательно обдуманное мнение, вместе с информацией и примерами, которые я собрал.

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

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

Обсуждения

Я приходил в подкаст The Changelog, чтобы поговорить о том, почему мейнтейнеры и контрьбьюторы должны вести логи изменений, а также о моей мотивации к созданию этого проекта.