Problem
Durable Workflow's prerelease version is repeated by hand across READMEs, SDK portals, installation examples, compatibility prose, generated LLM documents, and release qualification surfaces. These copies drift independently, so users can see several different releases described as current at the same time. Updating a release also creates avoidable cross-repository documentation work.
Product contract
Exact versions remain authoritative where machines need an immutable artifact identity: package metadata, release manifests, compatibility evidence, lockfiles, image tags, and reproducible retained evidence. User-facing onboarding should describe the supported channel and resolve the current compatible artifact without maintaining an RC sequence number in prose.
Acceptance criteria
- Replace hand-maintained exact prerelease numbers in installation instructions, SDK landing pages, READMEs, tutorials, compatibility examples, Sample App guidance, and generated LLM prose with tested versionless or prerelease-channel commands.
- Keep exact versions in package metadata, release manifests, immutable compatibility/conformance evidence, and generated reproducibility records.
- Where an exact user-visible pin is genuinely required, generate it from one machine-readable authority and label it as a qualified/reproducible tuple rather than a separately maintained current-version claim.
- Ensure the default installer, Composer, pip, Cargo, and CLI paths each resolve the currently supported prerelease in a clean environment without requiring users to discover an RC sequence number.
- Generate any derived install snippets and LLM surfaces from the same source instead of copying values between repositories.
- Add focused checks that detect hand-authored exact prerelease pins in onboarding surfaces without requiring arbitrary documentation sentences to be duplicated in tests.
- Remove or consolidate stale artifact-refresh work that exists only to chase copied prose versions.
Completion
A fresh PHP, Python, Rust, CLI, and Sample App onboarding pass reaches one compatible current product train while no public onboarding surface independently claims a different exact release is current.
Required source targets
durable-workflow/cli@main
durable-workflow/durable-workflow.github.io@main
durable-workflow/sample-app@main
durable-workflow/sdk-php@main
durable-workflow/sdk-python@main
durable-workflow/sdk-rust@main
durable-workflow/server@main
durable-workflow/workflow@v2
Problem
Durable Workflow's prerelease version is repeated by hand across READMEs, SDK portals, installation examples, compatibility prose, generated LLM documents, and release qualification surfaces. These copies drift independently, so users can see several different releases described as current at the same time. Updating a release also creates avoidable cross-repository documentation work.
Product contract
Exact versions remain authoritative where machines need an immutable artifact identity: package metadata, release manifests, compatibility evidence, lockfiles, image tags, and reproducible retained evidence. User-facing onboarding should describe the supported channel and resolve the current compatible artifact without maintaining an RC sequence number in prose.
Acceptance criteria
Completion
A fresh PHP, Python, Rust, CLI, and Sample App onboarding pass reaches one compatible current product train while no public onboarding surface independently claims a different exact release is current.
Required source targets
durable-workflow/cli@main
durable-workflow/durable-workflow.github.io@main
durable-workflow/sample-app@main
durable-workflow/sdk-php@main
durable-workflow/sdk-python@main
durable-workflow/sdk-rust@main
durable-workflow/server@main
durable-workflow/workflow@v2