Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 50 additions & 0 deletions docs/releases/v0.4.2/release-plan.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
# План релиза v0.4.2

## Метаданные

- Тег релиза: `v0.4.2`
- Тип повышения версии: `patch`
- Обоснование выбранной версии: совместимое дополнение документации — новая секция «Черновые коммиты» в `commits.md` и правило порядка «merge → удаление head-ветки» в `pull-request.md`; код валидатора и init-скрипта не менялся
- База рабочей ветки: `master` (`2fa53e6`)
- Рабочая ветка: `release/0.4.2`
- PR подготовки релиза в основную ветку: [#15](https://github.com/prikotov/git-workflow/pull/15)
- Ответственный: владелец проекта
- Плановая дата публикации: 2026-09-24

## Состав

- Включённый PR: [#14](https://github.com/prikotov/git-workflow/pull/14)
- Источник: задача калибровки конвейера сабагентов проекта-потребителя stocks2 ([PR #275](https://github.com/prikotov/stocks2/pull/275))
- `commits.md`: секция «Черновые коммиты» — формат `chore(<scope>): wip <что сделано> / черновик <что сделано>`, явное исключение из повелительного наклонения для пометки, пример; черновой коммит делает сам исполнитель — целенаправленно, на атомарном и логически завершённом этапе
- `pull-request.md`: в «Выполнение merge» — head-ветку удалять только после merge: удаление ветки до слияния автоматически закрывает PR

## Риски

- Проекты-потребители увидят новую секцию после повторного запуска `bin/git-workflow-init`; существующие локальные копии документации не перезаписываются автоматически — расхождение копий с пакетом возможно до переинициализации.
- Изменения docs-only: на код валидатора, init-скрипт и CI не влияют.
- Миграции данных и переменных окружения отсутствуют.

## Порядок публикации

1. Слить PR из `release/0.4.2` в `master` после успешного CI и одобрения.
2. Проверить совпадение содержимого одобренной ветки и коммита слияния.
3. Создать и отправить аннотированный тег `v0.4.2` на проверенный коммит слияния.
4. Создать GitHub Release по существующему тегу.

## Проверки перед публикацией

- `composer validate --strict`
- CI репозитория успешен
- Проверка относительных Markdown-ссылок и `git diff --check`
- Тег и ветка выпуска до начала подготовки свободны

## Проверки после публикации

- GitHub Release `v0.4.2` опубликован и указывает на ожидаемый SHA.
- Composer VCS metadata видит тег `v0.4.2`.

## Действия при проблеме после релиза

- Откат не используется; опубликованный тег не изменяется.
- Исправление выпускается новой patch-версией из тега `v0.4.2`.
- Координация: GitHub Issue и задача в `todo/`.
Loading