31 lines
1.5 KiB
Markdown
31 lines
1.5 KiB
Markdown
# Release and version policy
|
|
|
|
## Private development
|
|
|
|
- Workspace packages share one `0.0.x` version while contracts are private.
|
|
- Every user-visible or contract-affecting change is recorded under `Unreleased`.
|
|
- Machine-readable contracts carry their own positive integer schema version.
|
|
- Breaking schema changes increment that schema version and include rejection tests for
|
|
unsupported versions; consumers never guess.
|
|
- Temporary Kiln identifiers are never published, globally installed, or treated as
|
|
compatibility promises.
|
|
|
|
## Public releases
|
|
|
|
- Select and collision-check the final related naming system before the first public
|
|
package, crate, executable, configuration namespace, or IPC endpoint.
|
|
- Use Semantic Versioning for project packages; pre-1.0 compatibility remains explicit
|
|
rather than implied stable.
|
|
- A release derives from an annotated signed tag and clean repository state.
|
|
- Release records include source revision, toolchain, lockfile, package/source inventory,
|
|
hashes, SBOM, signatures, license notices, supported-platform matrix, and test evidence.
|
|
- Bit-for-bit reproducibility is claimed only after independent reproduction.
|
|
- No release resolves live AUR state or downloads unpinned executable installer plugins.
|
|
|
|
## Version ownership
|
|
|
|
The workspace version is changed once at the root and inherited by every project crate.
|
|
Provider protocol/schema versions remain independent when their compatibility boundaries
|
|
require it. Release tooling must reject mismatched workspace package versions.
|
|
|