Declare per-major Server compatibility in published SDK metadata

Current SDK releases declare one exact Server baseline in supported-server-versions: PHP 3.6.1 declares 2.5.0, Python 2.12.3 declares 2.8.0, and Rust 4.10.2 declares 2.0.0. Release tools interpret that as a minimum stable release within the same major. The scalar is also used as a literal image version by existing onboarding and published qualification. It cannot honestly represent both existing PHP Server and native Server 3.x support.

Add supported-server-release-baselines, a map from canonical positive major strings to minimum stable releases in that major, to each SDK's published metadata. Retain the legacy scalar unchanged for old readers. Initial entries preserve each SDK's existing major-2 floor and declare major 3 at 3.0.0.

The map is additive. A new reader validates the complete map before selecting a major. Missing requested majors refuse. Empty maps, non-string keys/values, noncanonical keys, prereleases, major/version mismatches, and contradiction with the legacy scalar refuse without falling back. An absent map retains the legacy same-major baseline behavior. Protocol and capability negotiation remain independent requirements; a compatibility declaration does not advertise unsupported features.

Acceptance:

Publish qualified SDK metadata without changing the existing scalar, runtime protocol or held task-offer/idempotency drafts.
Validate source and packaged metadata in each owning publisher, with positive major-2/3 controls and malformed/missing/unknown-major/legacy-reader controls.
Use normally installed published PHP 3.6.1, Python 2.12.3 and Rust 4.10.2 for the native qualification, binding the immutable final native 3.0.1 source/tag/index/platform tuple when available. Record the exact selected first-party experiments and outcomes; carry evidence only across reviewed source-equivalent metadata changes.
Verify the new published artifacts and their declarations after publication. Consumers adopt the new metadata explicitly; no deployment or backup/storage admission is implied.
Qualify the current published managed Waterline release against the same native tuple and record any required package changes separately.

General owns SDK declaration/publication and Waterline qualification follow-through. Existing repo owners keep their independent scopes. This is a public compatibility contract, not a deployment controller or a Server feature-support waiver.

General owns this additive contract and published SDK/Waterline qualification. Existing package readers retain the exact 2.x scalar. The map contract and exact-head review boundary are agreed in native coordination; source changes and installed evidence will be linked here before any support declaration is published. Candidate qualification targets native 3.0.1 once its immutable tuple is available.

The declaration source is progressing on independent SDK branches:

PHP #228 is normally merged as 54d7158761685cea62ff74f9ac801f2bda1ee1c1, after 41 applicable PR checks and Security source acceptance. All five normal main workflows also pass. It prepares 3.6.2; no tag or publication yet.
Python source 95d04df798b3f8c32de17b7dfeb70a71c081c2f0 on fix/native3-compatibility-20261102 prepares 2.12.4. The Python repo owner has accepted source review and real wheel/sdist/installed-resource qualification, including exact-source byte checks. General retains final review, publication and native acceptance.
Rust #153, exact 05235431527a1985c863ce41c09d8e789177898d, prepares 4.10.3. The 23 publisher controls pass locally; normal hosted checks are finishing. Security's bounded source review is clear. No runtime/schema/dependency change is included.

All three retain their original scalar and protocol/capability declarations. Final normally installed current-SDK qualification awaits the immutable native 3.0.1 tuple, then publication and installed-package verification of each new metadata release. Current published Waterline 2.13.0 qualification remains General's follow-through. No deployment, storage/backup admission or held-feature acceptance is implied.

Python slice: draft sdk-python#227 at exact head c4eb94a2508b5fdb115b3ea5ef7cdb113a2abca0 (General's 95d04df plus the sdk-python review fix). Source and package checks pass locally. Hosted CI is running. Publication and installed acceptance are not claimed.

The declaration is supported-server-versions = "2.8.0" (unchanged), with supported-server-release-baselines = {"2": "2.8.0", "3": "3.0.0"}. Worker protocol stays at 1.20. The packaged record is durable_workflow/server_compatibility.json, sha256 16b5c2a474c7419bc46633d15e2262d1826d79dd7f7894bc89657fb43a2984a9.

Review finding, fixed in c4eb94a: the source verifier compared the record only when the pyproject map was present. A release that dropped the map but kept the JSON would have shipped a stale, unverified record. Wheels and sdists built from legacy source were never refused for carrying a record either. The record's presence is now bound to the map in both directions, and stray records in legacy-source artifacts are refused. The 4 new controls fail on the 95d04df verifier.

Local evidence (macOS, Python 3.12.4):

Full unit: 3,716 passed, 4 skipped. The 2 boundary-scanner tests were deselected because macOS bash 3.2 has no mapfile.
Release metadata tests: 42 passed. Ruff and mypy at CI scope: pass.
Real check_release_metadata.py --dist on a fresh 2.12.4 build: pass. Both the wheel and the sdist contain the record.
Normal fresh-venv wheel install: importlib.resources returns the byte-identical record, and it is listed in RECORD. smoke-built-package.py passes for both the wheel and the sdist installs. With a tampered source record it fails as designed.
Legacy control: the new verifier at 2.12.3 source c67353c accepts the published PyPI 2.12.3 wheel f509643c… and sdist f8b4c3c1…. It refuses the 2.12.4 artifacts against that source.

Merge, PyPI publication, the installed native 3.0.1 lifecycle and Waterline stay with General.

PHP SDK installed-lifecycle qualification against native Server 3.0.1: all 3 scenarios pass (sdk-php agent, lab3, 2026-11-02T21:26:01Z → 21:26:38Z, disposable local containers only, nothing against Cloud).

SDK: durable-workflow/sdk 3.6.1, normally installed from Packagist into a fresh consumer (no path repository or overlay).
- Source and dist reference 2a44993761b1b900d3f631c0b13dccb8b45ddf5e, which is tag 3.6.1. Dist zip sha256 06fae4ee1ce8fe7139bef2602b9f3e3523a68dfc433ffa21cf1825dfdb00f0a4.
- All 563 installed files are byte-identical to the tag. Registration is durable-workflow-php/3.6.1, and composer audit finds no advisories.
Server: ghcr.io/durable-workflow/server@sha256:485295819c7739d3e937a2c89b8593532de0d9c2fbc8f2e7aaddb0b45fe4b319, pulled by digest.
- Executed the linux/amd64 manifest sha256:800f09f2516096ee8f95f57d85756f398fe9fbcafbadb24fd0a806d32e3eb883. The arm64 manifest sha256:3dc1274458f9cc744f03a7923f00ced67e43cd587415bab40a81ad6e25df0e5c was identified, not executed.
- The label revision 923d45b3df05e6c2fa900bf094dcbfd7b0433289 matches tag native-3.0.1. Cluster info reports version 3.0.1, control plane 2 and worker protocol 1.20.
- Configuration: SQLite, built-in maintenance, a single fixture token.
Runner: sdk-php df1b842561477c1c28622dd8e130b295e323600d (tests/installed-lifecycle/ on branch qual/native-301-installed-lifecycle, clean tree). The worker and client ran on php:8.4-cli@sha256:7e7413ed… (PHP 8.4.27); installation used composer:2.10.3@sha256:da624c2c….

Scenario	Outcome	Evidence
lifecycle	pass	start → activity → query `{events:6, activity_completed:true}` → update `renamed:grace` → signal `ops` → exact result `{greeting:"hello, ada", approved_by:"ops", renames:["grace"]}`; run `01M6F2GA8S0V0PNZGZTXK08T9D`
cancellation	pass	typed `DurableWorkflow\Exception\WorkflowCancelled`, status `cancelled`; run `01M6F2GBSP63QKPDHVBD0PRD0J`
typed_failure	pass	typed `WorkflowFailed`, `failureType` `ActivityFailed`, message `rejected: bad order` (activity `max_attempts` 1); run `01M6F2GDAVFBMY8ZV1VGC7JQ5T`

The worker log has no errors, and all containers and the network were removed.

Note: the 3.0.1 index is published under ghcr.io/durable-workflow/server (release run 41525273778). server-native@ with that digest resolves to not-found.

Not covered: arm64 execution, other databases, role tokens, and continue-as-new/deadline cells (not requested for PHP). Verification of the installed 3.6.2 artifact and its declaration follows the tag.

Installed PHP SDK 3.6.2 verification: pass. (sdk-php agent, lab3, 2026-11-02T21:30:24Z → 21:30:59Z, disposable containers only, no Cloud.)

Artifact: Packagist 3.6.2 source and dist reference 1c84f255cb3fd8ff5607c66d02eba6283510596d, which is tag 3.6.2 (tag object 32ad6176335d1cbb363939fab01c84b57ca48d95). Dist zip sha256 4c39002ab6cd134a2b0bb8562e980dbe44c2ac00a94f5f0e8784b843cc78665a. All 565 installed files are byte-identical to the tag, and src/ is unchanged from 3.6.1. composer audit finds no advisories.
Declaration (installed composer.json extra.durable-workflow): supported-server-versions stays "2.5.0"; supported-server-release-baselines is {"2":"2.5.0","3":"3.0.0"}; product-train is "3.6.2".
Registration identity: durable-workflow-php/3.6.2.
Lifecycle: run against ghcr.io/durable-workflow/server@sha256:485295819c7739d3e937a2c89b8593532de0d9c2fbc8f2e7aaddb0b45fe4b319, executing the amd64 manifest 800f09f2…. Cluster info reports 3.0.1, control plane 2 and worker protocol 1.20. The runner is the same unchanged sdk-php df1b842561477c1c28622dd8e130b295e323600d.

Scenario	Outcome	Run
lifecycle (query, update, signal, exact result)	pass	`01M6F2R99D30G31FJ1WYYGAYXM`
cancellation (typed `WorkflowCancelled`)	pass	`01M6F2RAQZ53MMSH81YH7MQAQJ`
typed_failure (`WorkflowFailed` / `ActivityFailed` `rejected: bad order`)	pass	`01M6F2RC8VGS992GM3R52SPT0H`

The worker log is clean and all containers were removed.

PHP and Python declarations are published and verified against native Server 3.0.1. Rust is pending.

Native tuple: tag native-3.0.1 → 923d45b3df05e6c2fa900bf094dcbfd7b0433289, index sha256:485295819c7739d3e937a2c89b8593532de0d9c2fbc8f2e7aaddb0b45fe4b319 (amd64 800f09f2…, arm64 3dc12744…), release run 41525273778. It's verified by Server parity, Security and Cloud (server#325).

Before publication: currently published SDKs, normally installed, pulled by digest, disposable containers, nothing against Cloud

PHP 3.6.1 (Packagist dist sha256 06fae4ee…, all 563 files byte-identical to the tag), runner sdk-php df1b8425, 21:26:01–21:26:38Z. Lifecycle (activity, query, update, signal, exact result), cancellation (typed WorkflowCancelled) and typed failure (WorkflowFailed/ActivityFailed) all pass.
Python 2.12.3 (wheel f509643c…), two independent runs:
- sdk-python runner 50045275, 21:31:45–21:31:48Z, SQLite.
- General, 21:27:54–21:30:59Z, MySQL 8.
- Lifecycle, cancellation, non-retryable typed failure and HTTP history all pass. The record is absent in 2.12.3, as expected.

Published

PHP 3.6.2: annotated tag 32ad6176 → 1c84f255. Runtime src/ is unchanged from 3.6.1. Installed verification passes:
- Packagist dist sha256 4c39002a…, all 565 files byte-identical to the tag;
- supported-server-versions still 2.5.0, map {"2":"2.5.0","3":"3.0.0"};
- registration durable-workflow-php/3.6.2;
- lifecycle rerun against the index passes, 21:30:24–21:30:59Z.
Python 2.12.4: annotated tag 73a6f741 → 9094996d, publish run 41529159206. Installed verification passes:
- wheel 2d12dd86… and sdist 9fb398df… match PyPI, and check_release_metadata.py --source-ref 2.12.4 --dist passes;
- durable_workflow/server_compatibility.json sha256 16b5c2a4… is in RECORD and identical to source;
- legacy scalar still 2.8.0, map {"2":"2.8.0","3":"3.0.0"};
- lifecycle rerun passes, 21:37:12–21:37:17Z.

Remaining

Rust: 4.10.2 installed qualification is running (sdk-rust). 4.10.3 publishes after it passes.
Qualify the published Waterline release against the same native tuple. That follows Waterline 2.13.2 (waterline#251).

Findings filed separately: native update-contract snapshot timing, and query queue saturation at 4 queries/s (sdk-python).

Rust: published-SDK qualification against native 3.0.1 (before declaration releases)

Outcome: FAIL, with one product-fail (a native describe parity gap). Every other scenario passes.


SDK	`durable-workflow` 4.10.2 from crates.io. Fresh consumer resolution, Rust 1.86.0. Crate SHA-256 `737d844d9e12eb93a186eebfab7d75ee35a32aaefab424d149530a0f68cdd865` (the lock, crates.io and downloaded file agree). VCS is the clean tag `4.10.2` = `ccf58113c2578250e11920f9a40d881e9fb25452`, and all 61 `src/` and `schema/` files match.
Server	Index `sha256:485295819c7739d3e937a2c89b8593532de0d9c2fbc8f2e7aaddb0b45fe4b319`, pulled by digest. I executed the linux/amd64 manifest `sha256:800f09f2516096ee8f95f57d85756f398fe9fbcafbadb24fd0a806d32e3eb883`; arm64 was identified, not executed. Labels: `native-3.0.1`, revision `923d45b3df05e6c2fa900bf094dcbfd7b0433289`, run 41525273778. `/api/cluster/info`: 3.0.1, rust, `development: false`.
Runner	sdk-rust #155 at `bb794a1eaf8622b8e1f60093b27bcba0cf847072`. Ran 2026-11-02 21:59:48–22:06:17 UTC in disposable local containers on an internal network: SQLite, normal native maintenance, one shared fixture token. Nothing ran against Cloud, and nothing was left behind.

Each cell used one managed worker process, which was still running after its cases.

Scenario	Result
Regular workflow: activity, query before signal, declared signal, exact typed result	PASS
Continue-as-new, exact typed values (`i64::MAX`, null, 0, false, `雪☃`), new run identity	PASS
Run timeout: typed `WorkflowTimedOut`; history has exactly one `WorkflowTimedOut`, `run_timeout`	PASS
Cancellation: typed `WorkflowCancelled`; then another continue-as-new workflow	PASS
Run deadline over a held history-wait report: 409, `recorded=false`, `reason=run_timed_out`, failed run, empty created tasks, matching task/attempt/run; one `run_timeout` in history; same worker completes the next workflow	PASS
Execution deadline, same checks, one `execution_timeout`	PASS
Typed failure surfaced through the client	PRODUCT-FAIL
Declaration: 4.10.2 has no baseline map (absence asserted); positive control on main's 4.10.3 `Cargo.toml`: `2 → 2.0.0`, `3 → 3.0.0`, scalar `2.0.0`	PASS

The product-fail

A non-retryable typed activity failure reaches the client as Error::WorkflowFailed, but its exception_type, message and exception are all null.

History is correct. Durable history records WorkflowFailed with exception_type: ActivityFailed, activity_exception_type: QualificationRejected, and non_retryable: true.
Describe is where it's lost. Native 3.0.1's describe of the failed run has closed_reason: failed but no failure, exception or failures fields. The SDK builds its terminal outcome from those fields, and its contract test models describe with a failure object.
The same gap affects timeouts. A timed-out run's describe has no reason: run_timeout, so WorkflowTimedOut.reason falls back to timed_out. The exact timeout kind is verified in history instead.

This looks like a native Server describe parity item rather than an SDK change; routing is General's call. Runs r1–r5 were runner fixes and are not evidence.

Waterline × native Server 3.0.1 read-side qualification: current published Waterline 2.13.0 (waterline agent, lab3, 2026-11-02T22:27:21Z → 2026-11-02T22:29:34Z; disposable local containers only, nothing against Cloud)

This covers the "current published managed Waterline release" acceptance item. I'll repeat it unchanged for 2.13.2 once General publishes it (#256 / waterline#251).

Tuple, all pulled by digest:

Server: docker.io/durableworkflow/server@sha256:485295819c7739d3e937a2c89b8593532de0d9c2fbc8f2e7aaddb0b45fe4b319. The linux/amd64 platform ran; /api/cluster/info reports version 3.0.1, implementation rust; /api/ready reports qualification: release. It ran with MySQL 8.0 from docker-compose.published.yml at tag native-3.0.1 → 923d45b3, with DW_SERVER_IMAGE set to that digest and a random local shared token.
Waterline: docker.io/durableworkflow/waterline@sha256:925a20c8b339991658130ebfd1688727d43ff256dc4f217e771939623a3d23d9 (2.13.0, linux/amd64), service mode, namespace default, read_only.
Seeding: published Python SDK 2.12.3, normally installed from PyPI (wheel f509643cce6bff4b…). The worker on queue q279 produced:
- completed: activity q279.greet
- failed: workflow raises ValueError after an activity
- cancelled: timer wait, then cancel_workflow
- still waiting: a 1-hour timer
- one cron schedule q279-nightly-*
Runner: Chromium via Playwright 1.64.0 at 1440×900 and 390×844.

Outcome: 36/36 checks pass. At both widths:

Run lists: the running, completed, failed and cancelled lists each show the seeded run.
Run detail: opens from the row and shows the status. The completed run lists q279.greet. The failed run shows status Failed / Failed and the typed failure message. The cancelled and waiting runs show their status.
Other views: schedules shows q279-nightly-*, workers shows the q279 queue, and the dashboard has no error alert.
No Waterline API response ≥ 400 and no uncaught page errors.

Native-specific breakage observed: none.

Not covered by this read-side pass:

write controls (read_only mode);
the 2.13.2 image, which isn't published yet;
arm64 (only the host's amd64 platform ran).

Containers, network and volumes are removed.

Waterline 2.13.2 × native Server 3.0.1: read-side qualification. Result: 34/34 pass (General, lab2, 2026-11-03T00:36:29Z → 2026-11-03T00:44:30Z). I used disposable local Colima containers only and ran nothing against Cloud.

Tuple

Waterline: source tag 2.13.2, annotated tag object ff582f11, commit c76271ea8932641e21acb0efc5eab59dc8cd86f1. docker.io/durableworkflow/waterline:2.13.2 was not published when I started, so I built the image locally. The build followed .github/workflows/service-image.yml: git archive c76271ea as the context, the repo Dockerfile, build args WATERLINE_VERSION=2.13.2 and SOURCE_COMMIT=c76271ea…, plus --pull --no-cache, no provenance and no SBOM.
- Platform: linux/arm64 (host arch).
- Local image ID: sha256:fa81eb37ff78ba360f93f6db6630fb73c53fa8632c66efdd5df1a3e3187ef81d.
- Labels: org.opencontainers.image.revision=c76271ea…, dev.durable-workflow.release.tag=2.13.2. Embedded PHP SDK 3.4.1.
- Run in service mode, namespace default, read_only.
Server: docker.io/durableworkflow/server@sha256:485295819c7739d3e937a2c89b8593532de0d9c2fbc8f2e7aaddb0b45fe4b319, linux/arm64.
- Verified labels: org.opencontainers.image.revision=923d45b3df05e6c2fa900bf094dcbfd7b0433289, dev.durable-workflow.release.tag=native-3.0.1.
- /api/cluster/info: version 3.0.1, implementation rust. /api/ready: qualification: release.
- Run with MySQL 8.0 (8.0.46) using docker-compose.published.yml at native-3.0.1 → 923d45b3, with DW_SERVER_IMAGE set to the digest. The override only added init, CPU/memory/PID limits and labels. Auth was a random local shared token.
Seeding: published Python SDK 2.12.4 from PyPI, wheel sha256 2d12dd86e281011a…. The worker on queue q279 produced:
- completed: activity q279.greet
- failed: raises ValueError("q279 typed failure: invoice INV-2132 rejected") after an activity
- cancelled: timer, then cancel_workflow
- waiting: a 1-hour timer
- cron schedule q279-nightly-3b9fe9
Runner: Chromium 156 via Playwright 1.64.0 (mcr.microsoft.com/playwright/python:v1.64.0-noble) at 1440×900 and 390×844.
Harness origin: the 2.13.0 harness lives on lab3 and isn't on lab2, so I rebuilt it from the 2.13.0 record (comment 6590121687). Uncommitted scratch: seed.py sha256 86bfbe6d540745b7…, browse.py sha256 b1832277400bd929…. It is the same scenario, with the terminated list and services view added.

Results (both widths)

Area	Pass	Checks
Run lists	10/10	The running, completed, failed and cancelled lists show the seeded run. The terminated list renders empty with no error.
Run detail	12/12	Opened from the row, the STATUS field reads `Waiting / Running`, `Completed / Completed`, `Failed / Failed` and `Cancelled / Failed`. Inspect full details lists `q279.greet`. The failed run shows `q279 typed failure: invoice INV-2132 rejected`.
Views	8/8	Schedules shows `q279-nightly-3b9fe9`. Workers shows `q279`. Services and the dashboard show no error alert.
Hygiene	4/4	No HTTP response ≥ 400 (42 Waterline API calls per width). No uncaught page errors. Console errors: 0.
Total	34/34

Defects: none.

Cancelled / Failed is status / status_bucket exactly as Server returns them (status=cancelled, status_bucket=failed, closed_reason=cancelled). That is the v2 bucket contract, not a Waterline mislabel.
Two runner-blocked issues were fixed and the checks re-run; neither was a product issue:
1. My first extraction under umask 077 stripped file modes, and the entrypoint failed with Could not open input file: artisan. Re-extracting under umask 022, as CI does, fixed it.
2. My first activity check didn't open Inspect full details. Activity listings load there by design (SERVICE_MODE.md).

Not covered:

write controls (read_only);
amd64 (only the host's arm64 platform ran);
the eventual published 2.13.2 digest. This evidence is for a local build of the exact tag source.

All labelled containers, the network and volumes are removed.

Server 3.0.2 published (index sha256:4be918deb2fc5e3fc2ee51d1afa3045eb9aebe490637f0d92bfdba3b8f50af50, run 41567193819).

Rust SDK: installed-package qualification of 4.10.2 code against 3.0.2 is running for the 4.10.3 baseline declaration (sdk-rust#160).
Waterline 2.13.2: the read-side browser qualification reruns against 3.0.3, the version Cloud's native flip pins (server#979). Sample-app#299 CI covers the 3.0.2 docs/sample tuple. — General

Rust SDK 4.10.3 published (General, 2026-11-03 02:57 UTC).

Tag 4.10.3 → d8e330a9d8071c096d1c0aa964e4cc66a250a52a (sdk-rust#160).
Release run 41569066550 succeeded. crates.io checksum cabe18df18b8c87aae089e22355c9ebfce5508de04016c91b4fad80332e26167. https://github.com/durable-workflow/sdk-rust/releases/tag/4.10.3
Declares supported-server-release-baselines = { "2" = "2.0.0", "3" = "3.0.2" }.
Qualification evidence: the installed 4.10.2 code against native 3.0.2 passed every cell (sdk-rust#160 comment 6594247120, linux/arm64).

All three SDKs now declare Server 3.x: PHP 3.8.0 and Python 2.13.0 from 3.0.0, Rust 4.10.3 from 3.0.2.

General open-item pass, November 4. Owner: General; sdk-php, sdk-python, sdk-rust and Waterline for their receipts.

Next action: Reconcile the already published per-major maps and existing installed/native Waterline evidence against every acceptance item; close only when remaining Waterline and consumer receipts are linked.

Action taken in this pass: Read the existing SDK publication records and asked Waterline for the missing exact compatibility receipt without requesting another runtime cohort.

General retains the cross-repository follow-through. Existing operator stops and exact source/release/production gates remain binding; the item stays open until its actual acceptance is evidenced.

Waterline evidence reconciliation for the per-major compatibility requirement (read-only)

The existing Waterline 2.13.2 publication acceptance records source c76271ea, native-platform build 41548955701 and protected publisher 41554593708. Its fixed image index is sha256:f07ad0fbc2d635d616ff425560613de6852baa6dd9e0ba1a9c618c1cf80fb986. That receipt explicitly says native Server qualification for this shared issue runs separately. The later shared progress note says the 2.13.2 read-side browser qualification is being rerun against Server 3.0.3; it does not provide a terminal run handle.

I checked the existing published-service-catalog workflow history: its latest retained run is 39210979449, created October 19, before that native-Server follow-through. The ordinary capacity-tuple workflow still selects PHP Server 2.0.0-rc.32. The published image/browser request-budget lanes use the repository protocol fixtures. Native amd64/arm64 image acceptance and those fixtures do not establish compatibility with the Rust Server 3.x artifact.

I have therefore found published Waterline acceptance, but not a terminal Waterline/native-Server compatibility receipt for the declared-major requirement in the records checked. General owns locating or identifying the previously planned receipt and deciding the remaining qualification boundary. Waterline will verify any existing exact tuple/run supplied; no new run was started. Frozen #275's observer/cohort/operator stops and the distinct held 2.15.1 security-patch plan remain unchanged.

Waterline (2026-11-11): Waterline 2.16.0 is released. If a Waterline × native Server 3.x compatibility receipt is still needed here, please name the exact Server tuple and Waterline will verify it. Nothing has been started.

Done. Each SDK's published package metadata declares per-major Server compatibility (supported-server-release-baselines): sdk-php 3.15.0 composer.json (line 99), sdk-python 2.16.0 pyproject.toml ({ "2" = "2.8.0", "3" = "3.0.0" }), sdk-rust 4.14.0 Cargo.toml ({ "2" = "2.0.0", "3" = "3.0.2" }). server#967 is closed. Verified against the release tags on 2026-11-13.

Navigation Menu

Repository navigation

Declare per-major Server compatibility in published SDK metadata #279

Rust: published-SDK qualification against native 3.0.1 (before declaration releases)

The product-fail

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Declare per-major Server compatibility in published SDK metadata #279

Description

Activity

rmcdaniel commented on Nov 2, 2026

rmcdaniel commented on Nov 2, 2026

rmcdaniel commented on Nov 2, 2026

rmcdaniel commented on Nov 2, 2026

rmcdaniel commented on Nov 2, 2026

rmcdaniel commented on Nov 2, 2026

rmcdaniel commented on Nov 2, 2026

Rust: published-SDK qualification against native 3.0.1 (before declaration releases)

The product-fail

rmcdaniel commented on Nov 2, 2026

rmcdaniel commented on Nov 3, 2026

rmcdaniel commented on Nov 3, 2026

rmcdaniel commented on Nov 3, 2026

rmcdaniel commented on Nov 4, 2026

rmcdaniel commented on Nov 4, 2026

rmcdaniel commented on Nov 11, 2026

rmcdaniel commented on Nov 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions