diff --git a/RELEASING.md b/RELEASING.md index f269b52..f094414 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -18,10 +18,12 @@ for completing this checklist and preserving the release controls it requires. - Run the repository validation at that exact commit and confirm the required CI run for that commit is successful. A green run for a nearby commit is not sufficient. -- For a release that claims adapter, dialect, transformation, or syntax-front - end support, collect the required adapter conformance and service-matrix - evidence for that same specification commit. Do not convert a - `release_candidate` claim into `released` before those gates pass. +- Gate a specification release on its normative artifacts, review, versioning, + repository validation, and exact-commit CI. Adapter conformance and + service-matrix evidence are downstream: they gate only an implementation's + support or conformance claims and package releases against the exact + specification commit and, once published, its release identifier. They do not + gate specification publication. - Confirm the changelog, versioning impact, and release notes describe only the included specification changes. @@ -47,6 +49,7 @@ for completing this checklist and preserving the release controls it requires. the intended full commit ID. - Verify the tag-triggered CI run is successful and that the release notes are visible from the repository release page. -- Record any remaining future-release gates in the roadmap. Publishing a - specification release never completes pending adapter or service-matrix - evidence by itself. +- Track implementation conformance and service-matrix work separately from + specification release gates. Publishing a specification does not assert + implementation conformance, and incomplete implementation evidence does not + block specification publication. diff --git a/ROADMAP.md b/ROADMAP.md index 58e8ed4..1169ae9 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -26,7 +26,9 @@ Prerequisite: the core mapping and canonical fixtures are stable enough to test ## 4. CI, releases, and documentation -- [x] Add continuous checks for specification links, schema examples, fixtures, and adapter conformance once the relevant repositories exist. +- [x] Add continuous specification-repository checks for links, schema examples, + and fixtures. +- [x] Define adapter conformance guidance; each adapter repository owns its runtime CI and evidence. - [x] Define versioning and compatibility guidance for the specification and profiles. - [x] Publish release notes and tagged specification releases; `v0.2.1` is the current public specification release and is immutable. @@ -45,7 +47,10 @@ Prerequisite: the SPSS profile, fixtures, and reference-adapter lessons are matu - [x] Define parameter binding, lineage, hashes, audit, metadata and weight propagation, dialect boundaries, and atomic publication. - [x] Add machine-readable positive and failure conformance cases. -- [ ] Run all cases in reference adapters before publishing profile 1.0. +- [ ] Publish profile 1.0 after its normative contract, declarative cases, and + specification-repository checks are complete. +- [ ] Require each implementation to pass the relevant cases before claiming + profile 1.0 conformance. ## 7. Canonical transformation plans and syntax frontends @@ -55,8 +60,9 @@ Prerequisite: the SPSS profile, fixtures, and reference-adapter lessons are matu machine-readable conformance cases. - [x] Define the in-place binding that preserves dataset/table identity on supported SQL profiles and never creates an OpenStatSpec undo/copy layer. -- [ ] Run the in-place apply service matrix against every claimed SQL profile - before publishing execution claims. +- [ ] Require each implementation to run the in-place apply service matrix + against every claimed SQL profile before publishing its execution claims; + this does not block specification publication. - [ ] Evaluate additional language frontends as separate adapters that lower to the same canonical plan. @@ -69,32 +75,42 @@ scope without creating a capability claim. - [ ] Select and pin Python and PHP driver stacks after fidelity and security evaluation. - [ ] Define T-SQL types, quoting, catalog binding, identity probes and effective-limit preflight. - [ ] Add exact cumulative-update CI services and complete conformance/fault-injection evidence. -- [ ] Publish an independent dialect profile only after both reference adapters pass the evidence gate. +- [ ] Publish an independent dialect profile after its normative T-SQL contract, + declarative cases, and specification-repository checks are complete. +- [ ] Require each reference adapter to pass the relevant evidence gate before + claiming Microsoft SQL Server support. - [ ] Evaluate Azure SQL identities separately; do not inherit a SQL Server claim implicitly. ## 9. Next release dependency order -The next release work must proceed in this order. Completion of an earlier -artifact is a dependency, not evidence that later adapter or service-matrix -work has passed. +The specification release and implementation claims have separate gates. The +specification defines and publishes the contract first; implementation evidence +follows and does not block specification publication. 1. [x] Merged Transformation Plan and SPSS Frontend profile 0.2 as unreleased, release-candidate work for the planned specification `v0.3.0`. -2. [ ] Rebase Python `0.5.0` conditional transformations on the lifecycle - implementation, pin the final profile commit, and pass the combined service - and conformance gates before making an adapter claim. -3. [ ] Migrate PHP to the canonical transformation plan and pass the same - relevant conformance cases before it claims conditional profile 0.2 support. -4. [ ] Select the exact intended `v0.3.0` commit and require that - same commit to pass repository validation and all required reference-adapter - gates. Only after those gates pass and release-tag signing or protection is - configured, create a signed or protected `v0.3.0` tag on that commit. +2. [ ] Complete and review the normative `v0.3.0` documents, schemas, + declarative fixtures, and hashes; select the exact release commit and pass + this repository's validation and CI on that commit. +3. [ ] After confirming release-tag signing or protection, create a signed or + protected `v0.3.0` tag on that commit, require its exact tag-context CI run + to pass, and follow the [release checklist](RELEASING.md) draft and control + verification before publishing the immutable release. Until then claims use `release_candidate`, a null release identifier, and the exact tested commit. +4. [ ] Have Python pin the exact specification commit and, once published, + record its `v0.3.0` release identifier; rebase conditional transformations + on the lifecycle implementation and pass the combined service and + conformance gates before making an adapter claim or package release. +5. [ ] Have PHP pin the exact specification commit and, once published, record + its `v0.3.0` release identifier; migrate to the canonical transformation plan + and pass the relevant conformance cases before making an adapter claim or + package release. The pending in-place service matrix and adapter conformance work in sections 6 -and 7 remains required; implementation package publication does not complete -either evidence gate. +and 7 are downstream implementation gates. They do not block the `v0.3.0` +specification release, and publishing the specification does not complete those +implementation evidence gates. ## Maintainer setup diff --git a/VERSIONING.md b/VERSIONING.md index 8f099bb..aff342f 100644 --- a/VERSIONING.md +++ b/VERSIONING.md @@ -28,7 +28,7 @@ The immutable commit is mandatory for both release candidates and stable release - for a published tagged release candidate, `specification_status` remains `release_candidate` and `specification_release` is the exact prerelease identifier whose target is the declared commit; and - for a published stable release, `specification_status` is `released` and `specification_release` is the exact release identifier whose target is the declared commit. -Development work on `main` is not a released standard. Release candidates may be used for interoperability testing but must be identified as such. A stable release is created only by a signed or protected tag after the repository validation and reference-adapter conformance gates pass. +Development work on `main` is not a released standard. Release candidates may be used for interoperability testing but must be identified as such. A stable specification release is created only by a signed or protected tag after this repository's normative-artifact, review, versioning, validation, and exact-commit CI gates pass. Reference-adapter conformance is downstream evidence for implementation claims and does not gate specification publication. A release-candidate tag is optional. An immutable commit is sufficient for CI and interoperability review. If maintainers publish a named release candidate, its protected or signed tag is recorded as `specification_release`, while the commit remains mandatory.