Files

T

Clément SAILLANT b69820e77b feat: release versioning — workflow, VERSION file, RELEASE.md (Plan 14)

- VERSION: 0.1.0 (synced with pyproject.toml)
- release.yml: tag-triggered pipeline (test → build → changelog → release)
- RELEASE.md: semver scheme, hotfix/backport process

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

2026-03-27 10:53:02 +01:00

2.6 KiB

Raw Permalink Blame History

Release Process

Versioning Scheme

Kill_LIFE follows Semantic Versioning (SemVer):

MAJOR (X.0.0) — incompatible API changes, breaking firmware protocol changes
MINOR (0.X.0) — new features (MCP tools, firmware capabilities, new board support)
PATCH (0.0.X) — bug fixes, documentation, non-breaking improvements

Pre-release suffixes: -alpha.N, -beta.N, -rc.N

The canonical version lives in the VERSION file at the repository root. pyproject.toml must stay in sync.

Creating a Release

Prepare the release branch (optional for patch releases):
```
git checkout -b release/0.2.0 main
```

Update the version:

echo "0.2.0" > VERSION

Also update pyproject.toml:

version = "0.2.0"

Commit the version bump:

git add VERSION pyproject.toml
git commit -m "chore: bump version to 0.2.0"

Create an annotated tag:

git tag -a v0.2.0 -m "Release 0.2.0 — short description of highlights"

Push the tag (this triggers the release workflow):
```
git push origin main
git push origin v0.2.0
```
The GitHub Actions workflow will:
- Validate the tag matches the VERSION file
- Run tests
- Build the Python package and firmware binary
- Create a GitHub Release with auto-generated changelog
- Attach build artifacts (.whl, .tar.gz, firmware.bin)

Hotfix Process

For urgent fixes against a released version:

Branch from the release tag:
```
git checkout -b hotfix/0.1.1 v0.1.0
```
Apply the fix, update VERSION to 0.1.1, commit.

Tag and push:

git tag -a v0.1.1 -m "Hotfix 0.1.1 — description of fix"
git push origin hotfix/0.1.1
git push origin v0.1.1

Merge the hotfix back into main:

git checkout main
git merge hotfix/0.1.1

Backport Policy

Critical security fixes: backported to the latest minor release branch.
Bug fixes: backported only if the affected version is still actively used on deployed hardware.
Features: never backported. Users should upgrade to the latest minor release.

Backport branches follow the naming convention backport/<fix-description>-to-<version>.

Pre-releases

For testing before a stable release:

echo "0.2.0-rc.1" > VERSION
git tag -a v0.2.0-rc.1 -m "Release candidate 1 for 0.2.0"
git push origin v0.2.0-rc.1

Pre-releases are automatically marked as such on GitHub when the tag contains -alpha, -beta, or -rc.

2.6 KiB Raw Permalink Blame History