79 lines
2.8 KiB
Markdown
79 lines
2.8 KiB
Markdown
---
|
||
name: release-workflow
|
||
description: Use when the user asks to release, bump version, update changelog/version files, or commit/push a repository release for the Planet repo. Applies the repo's versioning rules, updates all required version-bearing files, updates changelog/version-history, runs minimal relevant validation, and then commits/pushes when requested.
|
||
---
|
||
|
||
# Release Workflow
|
||
|
||
Use this skill for release-oriented work in this repository.
|
||
|
||
## When To Use
|
||
|
||
- The user asks to `发版`
|
||
- The user asks to bump a version
|
||
- The user asks to update `CHANGELOG`, `version-history`, or version files as part of a release
|
||
- The user asks to commit/push a release or a publishable bugfix/feature bundle
|
||
|
||
Do not use this skill for ordinary commits that are not being released.
|
||
|
||
## Versioning Rules
|
||
|
||
- `feature` -> bump `+0.1.0`
|
||
- `bugfix` -> bump `+0.0.1`
|
||
- `docs`, `maintenance`, and `refactor` do not bump by default unless the user explicitly wants a release
|
||
|
||
When intent is mixed, prefer the user’s stated release intent. If they ask to release a bugfix bundle, use a patch bump.
|
||
|
||
## Required Files
|
||
|
||
Every release bump must update these files together:
|
||
|
||
- `/home/ray/dev/linkong/planet/VERSION`
|
||
- `/home/ray/dev/linkong/planet/frontend/package.json`
|
||
- `/home/ray/dev/linkong/planet/pyproject.toml`
|
||
- `/home/ray/dev/linkong/planet/uv.lock`
|
||
- `/home/ray/dev/linkong/planet/docs/CHANGELOG.md`
|
||
- `/home/ray/dev/linkong/planet/docs/version-history.md`
|
||
|
||
## Workflow
|
||
|
||
1. Inspect the current worktree and current version.
|
||
2. Decide the release type from the user request:
|
||
- feature
|
||
- bugfix
|
||
- release without code changes
|
||
3. Compute the next version.
|
||
4. Update all required version-bearing files.
|
||
5. Add a concise but specific changelog entry:
|
||
- highlights
|
||
- important added/improved/fixed items
|
||
- mention the highest-signal files only
|
||
6. Update `docs/version-history.md`:
|
||
- current dev version
|
||
- new timeline row with summary
|
||
7. Run the smallest relevant validation available.
|
||
8. Before commit, verify the target version is present in all required files.
|
||
9. If the user asked for commit/push:
|
||
- stage the release files and code changes
|
||
- commit with a conventional message
|
||
- push to the requested branch, usually `dev`
|
||
|
||
## Validation Guidance
|
||
|
||
- Prefer scope-matched validation over broad expensive checks
|
||
- Typical examples:
|
||
- Python backend edits: `python3 -m py_compile ...`
|
||
- Frontend edits: use the project-standard frontend build/check if available
|
||
- If the environment prevents a check, say that explicitly in the final summary
|
||
|
||
## Release Checklist
|
||
|
||
Before closing the task, confirm:
|
||
|
||
- version bump applied consistently
|
||
- changelog updated
|
||
- version history updated
|
||
- generated/runtime artifacts are not accidentally staged
|
||
- validation status recorded
|
||
- commit and push completed if requested
|