Stability policy (ByteOr OSS)

    ByteOr OSS is currently pre-1.0.

    The default posture is conservative: documented contracts matter, but the workspace is still allowed to make breaking changes between minor versions while the design settles.

    Stable vs experimental

    The following are the clearest current contracts in the OSS workspace:

    • byteor-abi repr(C) layouts and generated header workflow
    • byteor-pipeline-spec v1 data model
    • deterministic kv encode/decode and canonicalization behavior for the v1 spec model

    The following remain more fluid even when they are useful today:

    • executor convenience helper APIs
    • SHM file naming/path conventions
    • runtime bring-up helper shapes
    • proc-macro ergonomics
    • xtask command surface and optional gate toggles

    Builder-first rule

    The builder-first API in byteor-pipeline-spec is the baseline authoring contract.

    • Macros are optional ergonomics.
    • A macro-only surface without an equivalent builder path is not the supported OSS baseline.

    Versioning

    • The workspace uses SemVer with the usual pre-1.0 convention.
    • Breaking changes bump the minor version (0.Y.0).
    • Non-breaking additions and fixes bump the patch version (0.Y.Z).
    • Until the v1 surface settles, the OSS crates move in lockstep to avoid dependency skew across the spec/kernel/backing/executor layers.

    Experimental feature flags

    New capabilities that are not ready for long-term support should be introduced behind feature flags prefixed with unstable-.

    Those flags are explicitly outside the initial OSS stability contract.

    Provenance
    Need the canonical source?
    Use the public hub to orient yourself, then jump to repo-owned docs or rustdoc when you need contract-level detail.
    Source-of-truth modelRepo docs index