Andrey
8e595bf7f2
- Deleted FIX_PROMLEMS.md and MONITORING_AUTH.md as they contained obsolete information regarding Prometheus and Alertmanager configurations. - This cleanup helps streamline the documentation and focuses on current setup practices.
125 lines
6.1 KiB
Markdown
125 lines
6.1 KiB
Markdown
# Инструкция по оформлению Release Notes
|
||
|
||
## Назначение
|
||
Этот документ описывает структуру и формат для создания файлов Release Notes (например, `docs/RELEASE_NOTES_DEV-XX.md`).
|
||
|
||
## Структура документа
|
||
|
||
### 1. Заголовок
|
||
```markdown
|
||
# Release Notes: [название-ветки]
|
||
```
|
||
|
||
### 2. Обзор
|
||
Краткий абзац (1-2 предложения), описывающий:
|
||
- Количество коммитов в ветке
|
||
- Основные направления изменений
|
||
|
||
**Формат:**
|
||
```markdown
|
||
## Обзор
|
||
Ветка [название] содержит [N] коммитов с ключевыми улучшениями: [краткое перечисление основных изменений].
|
||
```
|
||
|
||
### 3. Ключевые изменения
|
||
Основной раздел с пронумерованными подразделами для каждого значимого изменения.
|
||
|
||
**Структура каждого подраздела:**
|
||
```markdown
|
||
### [Номер]. [Название изменения]
|
||
|
||
**Коммит:** `[hash]`
|
||
|
||
**Что сделано:**
|
||
- [Краткое описание изменения 1]
|
||
- [Краткое описание изменения 2]
|
||
- [Краткое описание изменения 3]
|
||
```
|
||
|
||
**Правила:**
|
||
- Каждое изменение = отдельный подраздел
|
||
- Название должно быть кратким и понятным
|
||
- В разделе "Что сделано" используй маркированные списки
|
||
- НЕ перечисляй затронутые файлы
|
||
- НЕ указывай статистику строк кода
|
||
- Фокусируйся на сути изменений, а не на технических деталях
|
||
- Разделяй подразделы горизонтальной линией `---`
|
||
|
||
### 4. Основные достижения
|
||
Раздел с чекбоксами, подводящий итоги релиза.
|
||
|
||
**Формат:**
|
||
```markdown
|
||
## 🎯 Основные достижения
|
||
|
||
✅ [Достижение 1]
|
||
✅ [Достижение 2]
|
||
✅ [Достижение 3]
|
||
```
|
||
|
||
**Правила:**
|
||
- Используй эмодзи ✅ для каждого достижения
|
||
- Каждое достижение на отдельной строке
|
||
- Краткие формулировки (3-5 слов)
|
||
- Фокусируйся на ключевых фичах и улучшениях
|
||
|
||
### 5. Временная шкала разработки
|
||
Раздел с информацией о сроках разработки.
|
||
|
||
**Формат:**
|
||
```markdown
|
||
## 📅 Временная шкала разработки
|
||
|
||
**Последние изменения:** [дата]
|
||
**Основная разработка:** [период]
|
||
**Предыдущие улучшения:** [контекст предыдущих веток/изменений]
|
||
|
||
**Хронология коммитов:**
|
||
- `[hash]` - [дата и время] - [краткое описание]
|
||
- `[hash]` - [дата и время] - [краткое описание]
|
||
```
|
||
|
||
**Правила:**
|
||
- Используй реальные даты из коммитов
|
||
- Формат даты: "DD месяц YYYY" (например, "25 января 2026")
|
||
- Для времени используй формат "HH:MM"
|
||
- Хронология должна быть в хронологическом порядке (от старых к новым)
|
||
|
||
## Стиль написания
|
||
|
||
### Общие правила:
|
||
- **Краткость**: Фокусируйся на сути, избегай избыточных деталей
|
||
- **Ясность**: Используй простые и понятные формулировки
|
||
- **Структурированность**: Информация должна быть легко читаемой и сканируемой
|
||
- **Без технических деталей**: Не перечисляй файлы, классы, методы (только если это ключевая фича)
|
||
- **Без статистики**: Не указывай количество строк кода, файлов и т.д.
|
||
|
||
### Язык:
|
||
- Используй прошедшее время для описания изменений ("Добавлена", "Реализована", "Обновлена")
|
||
- Избегай технического жаргона, если это не необходимо
|
||
- Используй активный залог
|
||
|
||
### Эмодзи:
|
||
- 🔥 для раздела "Ключевые изменения"
|
||
- 🎯 для раздела "Основные достижения"
|
||
- 📅 для раздела "Временная шкала разработки"
|
||
- ✅ для чекбоксов достижений
|
||
|
||
## Пример использования
|
||
|
||
При создании Release Notes для новой ветки:
|
||
|
||
1. Получи список коммитов: `git log [base-branch]..[target-branch] --oneline`
|
||
2. Для каждого значимого коммита создай подраздел в "Ключевые изменения"
|
||
3. Собери основные достижения в раздел "Основные достижения"
|
||
4. Добавь временную шкалу с реальными датами коммитов
|
||
5. Проверь, что документ следует структуре и стилю
|
||
|
||
## Важные замечания
|
||
|
||
- **НЕ включай** информацию о коммитах, которые уже были в базовой ветке (master/main)
|
||
- **НЕ перечисляй** все файлы, которые были изменены
|
||
- **НЕ указывай** статистику строк кода
|
||
- **Фокусируйся** на функциональных изменениях, а не на технических деталях реализации
|
||
- Используй **реальные даты** из коммитов, а не предполагаемые
|