37 lines
1.7 KiB
Markdown
37 lines
1.7 KiB
Markdown
# Release policy
|
|
|
|
## Release metadata
|
|
|
|
`VERSION` is the runtime source of truth. Each published release must have:
|
|
|
|
- The same version in `VERSION`, the newest numbered `CHANGELOG.md` section and
|
|
the Git tag (`vX.Y.Z`).
|
|
- A changelog date matching its actual publication calendar date in Europe/Vienna.
|
|
- A tag pointing to the tested commit merged into `main`.
|
|
- Upgrade notes for API, runtime, storage or authentication changes.
|
|
|
|
The `Unreleased` section holds work awaiting the next release. A merge alone does
|
|
not publish a release. Under Semantic Versioning, incompatible documented API
|
|
changes require a major version, compatible features a minor version, and
|
|
compatible fixes a patch version. Do not rename or move existing published tags.
|
|
|
|
## Release checklist
|
|
|
|
1. Review changes since the previous release and determine the version from the
|
|
documented compatibility impact.
|
|
2. Update `VERSION`, move pending changelog entries into a dated version section,
|
|
leave a fresh `Unreleased` section and document upgrade steps.
|
|
3. Submit a release pull request and merge it through the protected `main` branch.
|
|
4. Verify the merge commit's CI and the version rendered by `raijuVersion()`.
|
|
Check that the release archive includes `VERSION` and the complete core.
|
|
For routing, login-destination or handler-directory changes, also record the
|
|
[Apache routing verification](ROUTING.md#required-verification) for that code.
|
|
5. Create an annotated `vX.Y.Z` tag on that exact merge commit.
|
|
6. Read back the tag target and the archive version.
|
|
|
|
## Release history
|
|
|
|
| Version | Date | Notes |
|
|
| --- | --- | --- |
|
|
| 1.0.0 | 2026-10-25 | Initial release, based on baseline commit `98067c90`. |
|