Skip to content

Allow modern hosts to compose the SDK with native Server - #279

Draft
rmcdaniel wants to merge 4 commits into
mainfrom
cli/native-dev-msrv
Draft

rmcdaniel wants to merge 4 commits into
mainfrom
cli/native-dev-msrv

Conversation

@rmcdaniel

@rmcdaniel rmcdaniel commented Nov 14, 2026 •

Copy link
Copy Markdown
Member

The SDK's exact bon=3.8.1 compatibility pin prevents a native host from resolving the SDK together with Server's official Avro 0.22 dependency (bon^3.9.1). The SDK now makes that direct pin optional behind the default-enabled msrv-1-86 feature. Default Rust 1.86 consumers retain it; a modern host can explicitly disable defaults to compose the two libraries.

This is a minor-release configuration change. Existing consumers using default-features=false must explicitly enable msrv-1-86 if they still require Rust 1.86. Other dependency edges can re-enable that feature through Cargo feature unification. Runtime SDK APIs, worker protocol behavior and the existing root lock are unchanged. The full Server/CLI engine, linker, platform and runtime qualification remain CLI-owned.

Validation at exact 60d99e64e894aafb9b39db98d9acd6181b82f747:

  • Rust 1.86 default/all-feature tests and the explicit defaults-disabled legacy-feature check pass.
  • Rust stable compiles a fresh isolated SDK + official Avro 0.22 consumer. Re-enabling only the legacy feature must reproduce the exact bon resolver conflict.
  • Package, documentation, regression corpus, boundary, CodeQL and Sonar checks pass.
  • Independent Python compatibility review and Security source review pass.

Avro protocol setup and the aggregate gate remain NONPASS because the shared bound PHP archive was retired upstream. Central #400 / #404 owns the reviewed archive/policy repair. Adopt only its normally qualified immutable helper revision and require fresh exact-head CI before merge. No package/tag/publication or installed composition result is established here.

@rmcdaniel

Copy link
Copy Markdown
Member Author

SDK owner decision: retain the default-enabled msrv-1-86 feature design for the next additive minor release, with the feature-configuration compatibility limit stated explicitly. Default Rust 1.86 consumers keep the exact existing bon pin. Consumers using default-features=false must explicitly enable msrv-1-86 if they require that compiler; omitting it permits newer dependency requirements. This is not an unqualified compatibility claim for every old feature configuration and will not be shipped as an unnoticed patch change.

At ff75c2a59029cc5c6ab510ca5af2e3acc06ae7b4, I merged the already accepted checkpoint API baseline, documented that boundary in README/CHANGELOG, and added focused normal CI checks. The Rust 1.86 job checks explicit compatibility with defaults disabled. The stable job compiles a fresh minimal consumer with the SDK and official apache-avro 0.22, then requires restoring the legacy pin to reproduce the bon resolver conflict. This separates the source dependency fix from CLI's actual linked engine and runtime qualification.

Local explicit-compatibility Rust 1.86 compilation, shell syntax and formatting pass. Fresh hosted modern-composition/default/package/quality checks and independent source review remain before integration. The shared bound PHP setup input replacement under central #297 separately blocks normal aggregate qualification; it is not bypassed. CLI may retain its exact-source compilation evidence at b470 with its own attribution, but neither that nor this decision is package publication or an installed result. SDK publication remains mine through the ordinary reviewed package and minor-release gates.

@rmcdaniel

Copy link
Copy Markdown
Member Author

The first modern-composition check at ff75 failed before compilation because the regression fixture itself exposed the negative sdk-msrv-pin forwarding feature. Cargo generates a workspace lock as though every workspace member feature is enabled, so that declaration admitted the incompatible legacy pin even for the intended positive case (Cargo resolver reference). The original failure remains in run43591975863.

Successor 60d99e64e894aafb9b39db98d9acd6181b82f747 removes that fixture feature. The positive consumer has only the explicit defaults-disabled SDK dependency. The negative metadata command then enables durable-workflow/msrv-1-86 directly and must still report the exact bon constraint conflict. SDK manifest/API semantics, compatibility prose and legacy check are unchanged. Fresh hosted validation remains required; neither case is claimed passing from this correction alone.

@sonarqubecloud

Copy link
Copy Markdown

@rmcdaniel

Copy link
Copy Markdown
Member Author

Python peer source/compatibility review: PASS for exact 60d99e64e894aafb9b39db98d9acd6181b82f747, scoped to the manifest/feature decision and the SDK+Avro composition fixture. I read the complete nine-file delta, including the corrected isolated fixture and CI commands; no runtime API source changes are present.

Default builds continue enabling the exact bon=3.8.1 pin through msrv-1-86. Disabling defaults now deliberately omits that direct pin, while explicitly enabling msrv-1-86 restores the legacy configuration. README and CHANGELOG state the Rust1.86 caveat for defaults-disabled fresh graphs and identify a minor-release configuration change, rather than claiming an unchanged universal MSRV or a compatible patch. This is consistent with Cargo's documented ability to state a specific Rust-version support policy.

The fixture isolates a fresh modern host with the SDK defaults disabled and official Apache Avro0.22. Its positive check and the subsequent explicit pin re-enable test the actual conflicting builder constraint, without declaring a negative forwarding feature in the fixture's workspace. The CI matrix keeps the full default/all-feature tests, adds the explicit Rust1.86 legacy check, and runs modern composition on stable. Cargo unifies features across dependency paths, so the opt-out remains valid only while no other dependency edge re-enables the pin; the negative control preserves that refusal.

The fixture establishes SDK+Avro dependency composition only. The full native Server/CLI engine, linker, platform and runtime qualification remain CLI-owned, as the PR body already states. I observed current Rust1.86/stable/package checks passing, including the modern composition step; the Avro protocol job is currently NONPASS and remaining checks must be resolved normally before integration. I ran no compiler, resolver, package build or runtime for this review and do not infer publication or installed compatibility from source.

@rmcdaniel

Copy link
Copy Markdown
Member Author

Security/source compatibility review PASS for exact 60d99e64e894aafb9b39db98d9acd6181b82f747.

The change preserves the existing default Rust 1.86 graph by making the exact bon =3.8.1 constraint optional but default-enabled through msrv-1-86. Only callers that explicitly disable defaults lose that resolver pin, and README/CHANGELOG state both the modern-host composition purpose and the requirement to re-enable msrv-1-86 when such callers still require Rust 1.86. Runtime SDK/API/protocol code is unchanged.

The composition fixture is closed to the intended boundary: its positive graph uses this SDK with defaults disabled plus official Avro =0.22.0, exercises both crates, and its separate negative command re-enables only durable-workflow/msrv-1-86 and requires the concrete bon 3.8.1/3.9.1 resolver conflict. CI also checks the defaults-disabled explicit feature under Rust 1.86. No dependency or lockfile evidence is borrowed into a runtime or publication claim.

The failed Avro/aggregate checks remain NONPASS because the shared PHP setup asset is retired; this verdict does not clear that integration gate. Adopt only the normally reviewed/qualified central setup successor, then require fresh exact-head CI before merge and normal package/publication follow-through.

This branch has not been deployed

No deployments
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