Viewing is open to everyone. Downloading and starring need a GitHub sign-in.
Sign in with GitHub
CONTRIBUTING_VERSIONING.md
v0.1.0-build.85
Latest
Commit ede38f5
Sign in with GitHub to download. Each download is recorded with your GitHub username.
| 1 | # Versioning and change rules |
| 2 | |
| 3 | These rules are mandatory for CKey contributors and coding agents. |
| 4 | |
| 5 | 1. **Establish the starting point.** Before work, inspect `git status`, the current branch and HEAD, `VERSION`, `CONTEXT.md`, the matching format specification, and current CI/toolchain definitions. Work from the newest committed repository state; do not rely on stale local artifacts or remembered context. |
| 6 | 2. **Version every change.** Every committed change that affects code, format, APIs, tests, fixtures, dependencies, docs, or build/release behavior increments `VERSION` to a new unique SemVer prerelease/build or release version. Update the public software version constant, release metadata, and `CONTEXT.md` in that same commit. Never silently replace an artifact while leaving its version unchanged. |
| 7 | 3. **Version each contract.** A wire-visible geometry, framing, ECC, rendering tolerance, or decode behavior change increments the format-spec version and format version field as appropriate. A public ABI/API incompatibility increments the major API version; compatible additions increment minor; fixes increment patch. SDK packages and interoperability fixtures identify the exact format and software/API versions they implement. |
| 8 | 4. **Pin and audit dependencies.** Toolchain, action, and runtime dependency versions must be pinned reproducibly (lockfiles or immutable action revisions). Use current supported upstream releases when upgrading, but do not float to an unreviewed “latest” dependency at build time. Run license/security audit on dependency additions and record the result. |
| 9 | 5. **Keep context current.** Update `CONTEXT.md` whenever scope, decisions, status, known limits, next gate, versions, dependencies, or validation results change. Include tests actually run and measured results; distinguish unimplemented from failing. Context must never claim a later version than `VERSION`. |
| 10 | 6. **Prove math, do not disguise data.** Any ECC, checksum, permutation, or synchronization algorithm must be specified with exact parameters, test vectors, and independent verification. Encoding bits with XOR masks, scrambling, encryption, or reversible transforms does not count as error correction. A masked or whitened representation may be added only as a separately specified modulation choice and never described as ECC. |
| 11 | 7. **Preserve review separation.** For critical subsystems, the author must not be the only reviewer. Record discipline review and resolution in the relevant PR or versioned engineering notes. A review may be performed in a later milestone, but then the component is marked experimental. |
| 12 | 8. **No unsupported claims.** Do not state that robustness, scan-time, capacity, or cross-platform interoperability targets are met without evidence from the documented benchmark and fixture procedures. |
| 13 | |
| 14 | The current implementation is an experimental milestone; it does not yet satisfy the independent decoder, real-camera, or independent review release gates. |