Raiju/RELEASES.md

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 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.