Compatibility and Versioning

Documentation version: 1.0
Last updated: 2026-09-27
Source revision: 6dd5716a8f3bcf29d27ae9ca64800bb517601236

This page records version markers and compatibility behavior present in the Sekura JS source revision above. It distinguishes tool releases from serialized artifact formats and proof semantics; these values are not interchangeable.

Product versions

The sekura-js and sekura-sjv command-line programs do not currently expose a product version or a --version option. The CMake project does not declare a project release version. The VS Code extension in sekura-sjs/ has its own package version, currently 0.1.0; that number does not identify either CLI or the SJP format.

The SJP manifest currently writes producer version unversioned-build. This is a placeholder, not a release identifier. Do not use it to infer which released CLI created an artifact.

Artifact and protocol version markers

Item Current marker Meaning
SJP ZIP manifest format_version: 2 Container/manifest format.
Legacy line-oriented SJP metadata version=1 Legacy representation; current replay handling does not replay it.
SJP attestation attestation_version: 1 Ed25519 attestation metadata format.
MR8 SOBJ 0x00010000 Binary object format version; the loader requires this exact value.
Verification environment JSON version: 1 Environment description schema; the reader expects this version.

SJP also carries a semantics_version. The current MR8 SJS/SOBJ proof path uses mr8-isa-program-proof-v3; the SystemVerilog proof path uses sjv-sv-rtl-proof-v1. These identify proof semantics, not SJP container or CLI releases.

SJS and SJV source files do not currently declare a language version in their source syntax.

Compatibility behavior

SJP format support is explicit: the current replay path reads format version 2. Legacy version=1 metadata is recognized as non-replayable. Do not assume a newer or older SJP can be replayed merely because its filename ends in .sjp; check the manifest format and supported semantics.

Proof dependency checks compare recorded target version, semantics version, environment, and source/object hashes. A mismatch makes the dependency stale; it is not silently treated as equivalent. MR8 SOBJ loading similarly rejects a binary whose version differs from 0x00010000.

There is no published compatibility matrix between numbered sekura-js and sekura-sjv releases yet, because the CLI products do not currently have release version numbers. Until releases are versioned, retain the source revision alongside reproducible build and verification records, and do not claim cross-version compatibility without checking the relevant artifact and semantics markers.

Initial distribution platforms

The initial launch targets are Windows x64 and macOS on Apple Silicon (arm64). Other operating systems and architectures are handled on request. This states the distribution target; it does not assert that packaged releases for these platforms have already been published or tested.

The current source does not define a release platform matrix or provide release binaries. Platform support for a particular release should be stated only after that release has been built and checked on the named platform.

Documentation version policy

The current documentation describes the implementation at the source revision listed at the top of each page. The site currently presents the current documentation; it does not provide separate versioned documentation sets or a stable selector.

When tagged product releases are introduced, document the shipped release separately from the current development state. Keep the current pages as the latest documentation, and label a documentation set stable only when it matches an actual released version. Record the source revision and supported platform builds for each release so readers can identify which implementation the documentation describes.