Примеры changelog

1. Рутинный SaaS-релиз

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

## 20 августа 2026

### Новое
- Сохранённые представления во входящих. Закрепите фильтр один
  раз и используйте его снова из боковой панели.

### Улучшено
- Задача экспорта теперь сообщает о прогрессе вместо того,
  чтобы казаться зависшей на крупных аккаунтах.

### Исправлено
- Приглашённые участники больше не видят пустую панель до
  первого входа.

2. API-релиз с устареванием

Читатель changelog API ищет одну вещь: собирается ли сломаться его интеграция и сколько у него времени. Поместите это наверх и дайте дату.

## Acme API 4.2 - 20 августа 2026

### Критические изменения
- `?page=` удалён во всех endpoint'ах списков. Используйте
  значение `nextCursor` из предыдущего ответа.
  `?page=` возвращает 400 после 1 октября 2026.
  Шаги миграции: acme.example/docs/pagination

### Новое
- Webhook'и можно ограничить одним проектом.

### Улучшено
- Endpoint'ы списков отвечают примерно в четыре раза быстрее на
  аккаунтах с более чем 10 000 записей.

3. Мобильный релиз

Магазины приложений показывают усечённое поле «что нового», а проверка может задержать сборку на дни. Оба факта формируют запись.

## iOS 3.4.0 - 20 августа 2026

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

### Также в этом релизе
- Более быстрый запуск на старых устройствах.
- Исправлен сбой при открытии ссылки, отправленной из Mail.

4. Исправление безопасности

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

## 20 августа 2026

### Безопасность
- Усилена проверка токенов сессии. Аккаунтам на самостоятельно
  размещённых установках следует обновиться до 4.2.1 или новее.
  Сообщено ответственно; доказательств эксплуатации нет.
  Подробности: acme.example/security/2026-08

5. Как выглядит плохая запись

Каждая строка здесь реальна по форме, и каждая строка — ошибка:

## v2.3.7

- Объединён PR #482 из feature/inbox-refactor
- lodash обновлён 4.17.20 -> 4.17.21
- Исправлена гонка данных в MembershipCache.resolve()
- Различные исправления багов и улучшения
- Рефакторинг модели SavedView (спасибо, Dave!)

Что общего у хороших

• Они описывают результат, а не реализацию. Читатель, который никогда не видел код, всё равно может сказать, затрагивает ли его запись.
• Они опускают вещи. Обновления зависимостей, рефакторинг, изменения CI и внутренние переименования отсутствуют, и это отсутствие делает остальное читаемым.
• Они ставят затратную вещь первой. Если что-то ломается, это первый заголовок, с датой.
• Они датированы способом, который читатель может использовать: номер версии там, где пользователи видят версии, дата там, где не видят.
• Они намеренно скучны. Никаких восклицательных знаков, никаких маркетинговых прилагательных, никаких «мы рады объявить». Люди, читающие changelog, ищут информацию и будут раздражены всем, что стоит у неё на пути.

Частые вопросы

Какой формат должен использовать changelog?

keepachangelog.com — самое близкое к стандарту, и названия его разделов (Added, Changed, Deprecated, Removed, Fixed, Security) широко распознаваемы. Это гораздо менее важно, чем формулировки внутри разделов. Последовательный формат с расплывчатыми записями хуже свободного формата с конкретными.

Как часто нам следует публиковать?

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

Должен ли changelog находиться на нашем сайте или на стороннней странице?

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

Пользователи действительно читают changelog'и?

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

Дополнительное чтение: changelog против релиз-нот, и Keep a Changelog, реально внедрённый.