Skip to content

Clarify maintenance release qualification and platform claims #37

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
rmcdaniel merged 1 commit into from
Sep 30, 2026
Merged

Clarify maintenance release qualification and platform claims #37

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 30 additions & 3 deletions docs/conformance.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -131,20 +131,47 @@ inspect update state after the original request has returned.

## Release gate

A release of the `dw` CLI must produce a passing harness result
document before tag, with the conformance level at `full` or
### Maintenance releases

Follow the organization [release follow-through guide](https://github.com/durable-workflow/.github/blob/main/AGENTS.md#cross-repository-release-follow-through).
Before tagging, record the changed behavior, affected consumers and required
experiments on the owning issue or release PR. Require normal command and
schema fixture tests on every supported PHP version, PHAR build and
reproducibility, and focused live Server checks for affected commands.

Publish through the protected release workflow. Verify every supported
distribution asset and exercise the changed behavior with the exact published
CLI and Server tuple. Record versions, digests, runner revision, commands and
scenario outcomes before closing the issue. A failed or incomplete required
experiment remains unfinished delivery and must be resolved.

These checks qualify the maintenance change. They do not establish full
platform conformance or replace a missing runtime scenario with a source test.
Do not label scoped evidence `full` or `provisional`, or add a platform
compatibility claim from it.

### Platform compatibility claims

A release publishing a platform compatibility claim must additionally produce
a passing harness result document before tag, with the conformance level at `full` or
`provisional` (provisional categories enumerated in release notes).
Use the suite version exposed by the exact Server build under test. The earlier
suite versions referenced in the fixture inventory above describe that
inventory's history and are not authority to omit newer required scenarios.

| Field | Value |
| --- | --- |
| Required claimed targets | `cli_json_client` |
| Required suite version | public docs-site manifest `durable-workflow.v2.platform-conformance.suite` version `27` |
| Required suite version | public manifest `durable-workflow.v2.platform-conformance.suite`, matching the Server build under test |
| CI job | CLI command contract tests in `composer test`; live runtime scenarios are recorded by the public platform conformance process |
| Block on `nonconforming` | yes |
| Artifact attached to release | harness result document, schema `durable-workflow.v2.platform-conformance.result` |

A `nonconforming` result blocks the release. A failure in a provisional
category emits a warning and does not block.
Every stable required runtime scenario must pass. Smoke subsets, missing cells
and runner failures cannot qualify a full platform claim. Attach the result
document to the release rather than claiming a harness ran from command tests.

## Cross-references

Expand Down
Loading