a8f9aa0bc6
* feat: migrate .opencode/ config from opencode * refactor: rename repo refs and sanitize for public * docs(handoff): add pr-7 handoff + ADR-002 * docs(handoff): fix PR number * docs: update project map with .opencode/ structure --------- Co-authored-by: opencode-agent <agent@slaid098.dev>
82 lines
No EOL
3.5 KiB
Markdown
82 lines
No EOL
3.5 KiB
Markdown
---
|
||
name: release
|
||
description: Выполняет релиз после мерджа PR — обновляет CHANGELOG, создаёт git tag и GitHub Release. Используй когда пользователь говорит "сделай релиз", "выпусти версию", "опубликуй", "release", "затегай". Also when user says "сделай релиз", "выпусти версию".
|
||
---
|
||
|
||
## Релиз
|
||
|
||
Выполняй релиз строго по шагам. НЕ пропускай шаги.
|
||
|
||
### Шаг 1: Проверки перед релизом
|
||
|
||
- Убедись, что мы на основной ветке (`main` или `master` — проверь какая основная)
|
||
- `git status` — working tree должен быть чистым
|
||
- Если нет → **СТОП**, сообщи пользователю
|
||
|
||
### Шаг 2: Определить версию
|
||
|
||
- Получи последний тег: `git tag --sort=-version:refname | head -1` (например `v2.7.6`)
|
||
- Покажи коммиты с последнего тега: `git log vLAST..HEAD --oneline`
|
||
- Предложи версию на основе коммитов:
|
||
- `feat(...)` → minor bump (например `v2.7.6` → `v2.8.0`)
|
||
- `fix(...)`, `docs(...)`, `chore(...)` → patch bump (`v2.7.6` → `v2.7.7`)
|
||
- Если коммитов с последнего тега нет → **СТОП**, нечего релизить
|
||
- Спроси подтверждение версии у пользователя (через question tool или текстом)
|
||
|
||
### Шаг 3: Обновить CHANGELOG.md
|
||
|
||
Проверь формат changelog. Если файл существует и использует [Keep a Changelog](https://keepachangelog.com/) формат:
|
||
|
||
1. Переименуй `## [Unreleased]` в `## [X.Y.Z] - YYYY-MM-DD` (сегодняшняя дата)
|
||
2. Добавь новый пустой `## [Unreleased]` выше
|
||
3. Заполни секции на основе коммитов:
|
||
- `feat(...)` → `### Added`
|
||
- `fix(...)` → `### Fixed`
|
||
- `chore(...)`, `refactor(...)` → `### Changed`
|
||
- `docs(...)` → можно опустить или `### Changed`
|
||
|
||
Если changelog в другом формате — адаптируй под существующий стиль.
|
||
|
||
### Шаг 4: Коммит changelog
|
||
|
||
```bash
|
||
git add CHANGELOG.md
|
||
git commit -m "docs: add vX.Y.Z changelog entry"
|
||
```
|
||
|
||
### Шаг 5: Создать tag
|
||
|
||
Lightweight tag (не annotated):
|
||
|
||
```bash
|
||
git tag vX.Y.Z
|
||
```
|
||
|
||
### Шаг 6: Push
|
||
|
||
```bash
|
||
git push
|
||
git push --tags
|
||
```
|
||
|
||
### Шаг 7: GitHub Release
|
||
|
||
```bash
|
||
gh release create vX.Y.Z --title "vX.Y.Z" --notes "<содержание секции из changelog>"
|
||
```
|
||
|
||
### Шаг 8: Отчёт
|
||
|
||
Сообщи пользователю:
|
||
- Версию релиза
|
||
- Ссылку на GitHub Release
|
||
- Количество коммитов в релизе
|
||
|
||
## Safety rules
|
||
|
||
- НИКОГДА не делай релиз, если working tree не чистый
|
||
- НИКОГДА не делай релиз, если нет новых коммитов с последнего тега
|
||
- НИКОГДА не создавай тег с существующим именем
|
||
- ВСЕГДА спрашивай подтверждение версии у пользователя перед коммитом
|
||
- НЕ обновляй `pyproject.toml` version (в некоторых репо версионирование через tags)
|
||
- НЕ делай `git push --force` |