Qiskit / coheriq

86%

LAST BUILD ON BRANCH main

branch: SELECT

CHANGE BRANCH

x

Sync Branches

• No branch selected
• document-fork-safety
• engine-lock-ordering
• garrison-patch-1
• gh-readonly-queue/main/pr-10-b76e9ac612e1d3788975b57da74118459ece3678
• gh-readonly-queue/main/pr-11-eb9c534fec06ae2d7bc8993116af55950429049f
• gh-readonly-queue/main/pr-12-494500368677b4aa652d16f496cad3ea5e3100ae
• gh-readonly-queue/main/pr-13-197500fb5da27eebf1603b562fd389c36a24323a
• gh-readonly-queue/main/pr-9-8ef72f6b01ddce23ced97781d4165f480d550fe9
• initial-ci
• main
• readme-absolute-links
• require-materialized-domain
• semver-policy
• test-ragged-on-all-platforms
• update-agents-architecture

Build # 35925307984

Build Type

push

github

Committed by web-flow

Commit Message

Document the pre-1.0 stability policy (#13)

Coheriq is built to be depended upon by separately published domains and
engines, but plain 0.y.z semantic versioning gives those consumers no way
to express a useful version range: the version number does not distinguish
a release that adds features from one that breaks them, so the only safe
upper bound is the next minor.

State a policy that makes a range dependable. Until the major version is
non-zero, a breaking change to the consumer-facing interface advances the
minor version to the next multiple of ten, so a downstream package can
depend on coheriq>=0.4,<0.10 and pick up bug fixes and new features
without a pin bump. Patchlevel releases stay bug-fix only. The end-user
interface for enabling an engine is explicitly not covered by that
promise and may change in an ordinary minor release.

Remove the note at the top of the README saying the code should not be
considered stable; the new section supersedes it.

Assisted-by: Claude Opus 5

Coverage Stats

185 of 215 relevant lines covered (86.05%)

0.86 hits per line