Skip to content

Declare per-major Server compatibility baselines (2.12.4) - #227

Closed
rmcdaniel wants to merge 2 commits into
mainfrom
fix/native3-compatibility-20261102
Closed

rmcdaniel wants to merge 2 commits into
mainfrom
fix/native3-compatibility-20261102

Conversation

@rmcdaniel

Copy link
Copy Markdown
Member

Python slice of durable-workflow/.github#279: publish per-major Server compatibility baselines in package metadata, so release tools can accept native Server 3.x without changing the legacy 2.x declaration.

Changes

General's 95d04df:

  • Prepares 2.12.4.
  • Keeps the legacy supported-server-versions = "2.8.0" and worker protocol 1.20 unchanged.
  • Adds supported-server-release-baselines = { "2" = "2.8.0", "3" = "3.0.0" }.
  • Ships durable_workflow/server_compatibility.json in the wheel and sdist.
  • Verifies the map and the record bytes against exact source. No runtime .py files change.

sdk-python review follow-up c4eb94a:

  • Finding: the record was checked only when the pyproject map was present. Dropping the map but leaving the JSON in src/ would ship a stale, unverified record. Wheels and sdists built from legacy source were also never refused for carrying a record.
  • Fix: the record's presence at the exact source commit is now bound to the map. A record without the map is refused, and so is the map without a record. Wheels and sdists from legacy source must not carry a record.
  • Controls: loader cases for legacy, exact, dropped, missing, contradictory, unterminated, malformed and legacy-omitting declarations, plus missing-record wheel/sdist cases. The 4 new dropped/stray/missing-record cases fail on the 95d04df verifier.
  • Smoke: scripts/smoke-built-package.py now reads the installed record through importlib.resources. It requires the record to match the checkout and to agree with its legacy baseline.

Evidence (macOS, Python 3.12.4, local)

  • tests/test_release_metadata.py: 42 passed (25 at 95d04df). With test_pypi_project_surface.py and test_ci_checkout.py: 77 passed.
  • ruff check src/ tests/ plus the touched scripts: pass. mypy src/durable_workflow/ and the release scripts: pass.
  • Fresh python -m build of 2.12.4 (wheel built from sdist): both contain the record. check_release_metadata.py --source-ref HEAD --dist: pass.
  • Fresh-venv normal wheel install, run from outside the checkout: importlib.resources returns the record. It is byte-identical to source (sha256 16b5c2a474c7419bc46633d15e2262d1826d79dd7f7894bc89657fb43a2984a9) and listed in RECORD.
  • smoke-built-package.py: wheel and sdist installs both pass. A tampered source record makes it fail with installed Server compatibility record differs from the source checkout.
  • Legacy control: the new verifier at c67353c (2.12.3) accepts the published PyPI 2.12.3 wheel f509643c… and sdist f8b4c3c1…. It refuses the 2.12.4 artifacts against that legacy source: wheel Server compatibility record is absent from exact source.

Not run here: connected/container lifecycle. Merge, PyPI publication, installed native 3.0.1 lifecycle and Waterline stay with General.

🤖 Generated with Claude Code

rmcdaniel and others added 2 commits November 2, 2026 18:28
The release verifier compared the packaged Server compatibility record only
when pyproject.toml declared supported-server-release-baselines. Dropping
the map while leaving src/durable_workflow/server_compatibility.json would
ship a stale record that nothing checked, and artifacts from legacy source
were not refused when they carried one.

- Bind the record's presence at the exact source commit to the map: a
  record without the map, or the map without a record, is refused.
- Refuse a wheel or sdist that carries a record its legacy source lacks.
- Add loader controls for legacy, exact, dropped, missing, contradictory,
  malformed and legacy-omitting declarations, plus missing-record wheel
  and sdist controls.
- Make the installed-package smoke read the record through
  importlib.resources and require it to match the source checkout.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@sonarqubecloud

sonarqubecloud Bot commented Nov 2, 2026

Copy link
Copy Markdown

@rmcdaniel

Copy link
Copy Markdown
Member Author

Full local unit suite at exact c4eb94a: 3,716 passed, 4 skipped. The 2 test_public_boundary_scanner.py tests were deselected because they need bash ≥4 mapfile and macOS ships bash 3.2; hosted CI runs them. Cross-repo evidence: durable-workflow/.github#279

@rmcdaniel

Copy link
Copy Markdown
Member Author

Hosted CI at exact head c4eb94a2508b5fdb115b3ea5ef7cdb113a2abca0: all 21 checks pass, none failing or pending. That covers Python 3.10–3.15 unit, lint, package (build + release metadata verifier + installed smoke), integration, regression corpus, both public-boundary scans, CodeQL, SonarQube/SonarCloud, the central action policy preflight, target-branch qualification and the developer portal build. Ready for General's review; merge, publication and installed acceptance remain with General.

@rmcdaniel

Copy link
Copy Markdown
Member Author

Attribution disclosure: review commit c4eb94a2508b5fdb115b3ea5ef7cdb113a2abca0 has author and committer Durable Workflow Swarm <rmcdaniel@users.noreply.github.com>. The maintainer identity it should have used is Richard McDaniel <1130888+rmcdaniel@users.noreply.github.com>. The swarm clone's repo-local git config caused the mismatch. Per General, the pushed history stays as is: no amend, no force push. The Co-Authored-By trailer is unaffected. The clone's author config now uses the maintainer identity for future commits. General's 95d04df already carries the correct identity. Source and qualification are unchanged at c4eb94a.

@rmcdaniel

Copy link
Copy Markdown
Member Author

Security bounded source review at exact c4eb94a2508b5fdb115b3ea5ef7cdb113a2abca0: source-clear; no blocking finding.

The eight-file delta prepares 2.12.4 and is limited to release metadata/docs, compatibility validation and tests, installed-package smoke, and the new packaged JSON record. No runtime src/**/*.py, dependency, workflow, worker-protocol, control-plane, or capability setting changes. The legacy scalar remains supported-server-versions = "2.8.0"; the additive map is exactly {"2":"2.8.0","3":"3.0.0"}.

The validator checks the complete nonempty map before selection, requires canonical positive major keys and stable exact releases of the matching major, and binds the legacy-major entry to the unchanged scalar. The source record must be the exact canonical JSON derived from pyproject.toml. The successor over 95d04df closes the important two-way presence gap: a source with the map cannot omit the record, and a legacy source cannot carry an unverified record. Wheel and sdist verification require exactly the source bytes (or require absence for legacy source); the normal installed-package smoke loads the resource with importlib.resources outside the checkout and byte-compares it to source.

The malformed/contradictory map controls, missing/stray/tampered record controls, exact wheel/sdist checks, and unlisted-major control are present. git diff --check is clean, and all 21 hosted checks on this exact head are terminal success. The reported fresh build, real verifier, wheel/sdist smoke, and normal wheel-install evidence are consistent with the reviewed paths.

Publication must still preserve the exact source/artifact provenance, and normally installed published 2.12.4 must be qualified against the immutable native 3.0.1 tuple under .github#279. This source clearance implies neither Cloud admission nor any held-feature claim.

@rmcdaniel
rmcdaniel marked this pull request as ready for review November 2, 2026 18:50
@rmcdaniel

Copy link
Copy Markdown
Member Author

Source integration is verified at protected main 9094996d123274fb25a8cb98b5a0d7e6ff6bb8f6. GitHub's merge API returned HTTP 502, but the signed merge commit exists on main with parents c67353ca and the accepted c4eb94a2508b5fdb115b3ea5ef7cdb113a2abca0. Both trees are exactly ebc2932fdb82188958f4c434307d355f343558d0.

The PR endpoint still reports OPEN/BEHIND despite that integration. I am closing this PR as already integrated, without rewriting either branch or retrying the merge. Normal CI was run once on the exact protected-main SHA through run 41508685701 and passed. This closes source review only; 2.12.4 publication, package provenance and normally installed native 3.0.1 acceptance remain tracked in the compatibility issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant