Mirror of https://github.com/roostorg/osprey
github.com/roostorg/osprey
docs: move release process to its own section (#161)
authored by
Cassidy James Blaede
and committed by
GitHub
ac59500a
9de1c744
+37
-37
-37
docs/DEVELOPMENT.md
-37
docs/DEVELOPMENT.md
···
135
135
136
136
[More about rules →](rules.md)
137
137
138
-
## Release Process
139
-
140
-
Osprey 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.
141
-
142
-
### Patch releases (1.x.y)
143
-
144
-
Patch releases are backward-compatible fixes or small improvements already merged to `main`.
145
-
146
-
Cut a patch release when:
147
-
148
-
- Downstream users need a stable version tag, or
149
-
- Meaningful fixes have accumulated and CI is green
150
-
151
-
There is no fixed cadence; releases are event-driven.
152
-
153
-
### Patch release checklist
154
-
155
-
Before cutting a release:
156
-
157
-
- [ ] Code quality CI passing on `main` (see [Code Quality Checks](https://github.com/roostorg/osprey/actions))
158
-
- [ ] No breaking changes
159
-
- [ ] [CHANGELOG.md](../CHANGELOG.md) updated (if applicable)
160
-
161
-
### How to cut a release
162
-
163
-
1. Ensure the checklist above is satisfied.
164
-
2. In GitHub: **Releases** → **Draft a new release**.
165
-
3. Choose or create a tag `X.Y.Z` (e.g. `1.0.1`) from `main`.
166
-
4. Publish the release.
167
-
168
-
Publishing the release triggers existing automation:
169
-
170
-
- **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)).
171
-
- **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)).
172
-
173
-
Downstreams can depend on version tags (e.g. `1.0.1`) instead of commit SHAs.
174
-
175
138
## Test Data
176
139
177
140
Generate sample JSON actions:
+1
docs/SUMMARY.md
+1
docs/SUMMARY.md
···
7
7
- [Tools Overview](development/tools.md)
8
8
- [Troubleshooting](development/troubleshooting.md)
9
9
- [IDE Setup](development/ide.md)
10
+
- [Release Process](development/releases.md)
10
11
- [User Interface](UI.md)
11
12
- [Writing Rules](rules.md)
12
13
- [User Research & Personas](user_personas.md)
+36
docs/development/releases.md
+36
docs/development/releases.md
···
1
+
# Release Process
2
+
3
+
Osprey 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
+
7
+
Patch releases are backward-compatible fixes or small improvements already merged to `main`.
8
+
9
+
Cut a patch release when:
10
+
11
+
- Downstream users need a stable version tag, or
12
+
- Meaningful fixes have accumulated and CI is green
13
+
14
+
There is no fixed cadence; releases are event-driven.
15
+
16
+
## Patch release checklist
17
+
18
+
Before 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
+
26
+
1. Ensure the checklist above is satisfied.
27
+
2. In GitHub: **Releases** → **Draft a new release**.
28
+
3. Choose or create a tag `X.Y.Z` (e.g. `1.0.1`) from `main`.
29
+
4. Publish the release.
30
+
31
+
Publishing 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
+
36
+
Downstreams can depend on version tags (e.g. `1.0.1`) instead of commit SHAs.