Mirror of https://github.com/roostorg/osprey
github.com/roostorg/osprey
1# Release Process
2
3Osprey uses [Semantic Versioning](https://semver.org/) (SemVer) with a 1.x.y series. This is a lightweight, bootstrap release process so downstream users can depend on version tags instead of commit hashes. The process may evolve as project usage grows.
4
5## Patch releases (1.x.y)
6
7Patch releases are backward-compatible fixes or small improvements already merged to `main`.
8
9Cut a patch release when:
10
11- Downstream users need a stable version tag, or
12- Meaningful fixes have accumulated and CI is green
13
14There is no fixed cadence; releases are event-driven.
15
16## Patch release checklist
17
18Before cutting a release:
19
20- [ ] Code quality CI passing on `main` (see [Code Quality Checks](https://github.com/roostorg/osprey/actions))
21- [ ] No breaking changes
22- [ ] [CHANGELOG.md](https://github.com/roostorg/osprey/blob/main/CHANGELOG.md) updated (if applicable)
23
24## How to cut a release
25
261. Ensure the checklist above is satisfied.
272. In GitHub: **Releases** → **Draft a new release**.
283. Choose or create a tag `X.Y.Z` (e.g. `1.0.1`) from `main`.
294. Publish the release.
30
31Publishing the release triggers existing automation:
32
33- **osprey-rpc**: build and attach sdist (and zip) to the release ([release-osprey-rpc](https://github.com/roostorg/osprey/blob/main/.github/workflows/release-osprey-rpc.yml)).
34- **Osprey Coordinator**: build and push Docker image to GHCR with version tags ([publish-coordinator-image](https://github.com/roostorg/osprey/blob/main/.github/workflows/publish-coordinator-image.yml)).
35
36Downstreams can depend on version tags (e.g. `1.0.1`) instead of commit SHAs.