Ведите changelog

Не позволяйте своим друзьям сливать логи Git в changelog’и.

Version 1.1.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

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

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

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

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

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

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

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

Руководящие принципы

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

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

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

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

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

Это служит достижению двух целей:

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

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

Да. Вот несколько причин, по которым они могут оказаться совершенно бесполезными.

Diff’ы лога коммитов

Использование diff’ов лога коммитов в качестве лога изменений — это плохая идея: они полны информационного шума от слияния коммитов, от коммитов с непонятными заглавиями, от изменений, вносимых в документацию, и т. п.

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

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

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

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

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

Даты, сбивающие с толку

Региональные форматы дат различаются по всему миру, и зачастую трудно найти удобный для человека формат, который был бы интуитивно понятен каждому. Преимущество дат в форматах наподобие 2017-07-17 заключается в том, что элементы в них следуют в порядке от более крупной единицы измерения к более мелкой: год, месяц и день. К тому же, в отличие от некоторых региональных форматов, в которых изменено положение чисел, обозначающих день и месяц, этот формат не пересекается с другим и не вызывает неоднозначных толкований. Исходя из этих причин и того факта, что этот формат соответствует стандарту ISO, именно он рекомендован для записей в логе изменений.

Непоследовательное освещение изменений

Лог, в котором упомянуты лишь некоторые изменения, может быть опасен в той же мере, что и отсутствие лога изменений. Несмотря на то, что многие изменения могут быть нерелевантными (например, удаление одного пробела не во всех случаях может нуждаться в регистрации), в логе следует упоминать о любых важных изменениях. При непоследовательном освещении изменений ваши пользователи будут заблуждаться, считая лог изменений единственным источником истины. А ведь таким он и должен быть. С большой силой приходит большая ответственность — наличие хорошего лога изменений означает наличие последовательно обновляемого лога изменений.

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

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

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

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

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

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

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

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

Что насчёт функции «Релизы» на GitHub’е?

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

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

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

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

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

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

Что насчёт yanked-выпусков?

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

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

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

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

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

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

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

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

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

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

Обсуждения

Я приходил на подкаст The Changelog, чтобы поговорить о том, почему maintainer’ам (персоналу сопровождения) и контрибуторам следует озаботиться ведением логов изменений, а также о мотивах, стоящих за этим проектом.