You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Show which Helm chart version pairs with each Server version #346
Overriding image.tag to a different Server version isn't validated or documented.
Acceptance criteria
The compatibility tuple includes the Helm chart version that pins the published Server version, generated from the same release data as the other rows.
The deployment guide states that one chart release is tested with one Server version, and explains how to choose a chart for a given Server version and what overriding image.tag means.
Accepted as a release-metadata documentation improvement. The chart/server pairing already exists in the chart contract; the site needs to expose it from the same machine-owned release data as the other compatibility rows.
Add the exact published chart version and its tested Server appVersion, validate their relationship during the normal documentation build, and explain chart selection and image overrides in the deployment guide. An override is a custom tuple until it receives its own qualification. Apply the guide changes and source hashes in all eight locales. Do not maintain a second handwritten version table.
This follows the active P1 artifact deliveries and can include their exact published Server/chart pair after acceptance. No new runtime capability is required, and no unpublished chart or image is represented as qualified.
Scope addition: the docs site links only the chart source folder, not the chart's upgrade notes, which hold the version policy and per-release migration notes.
Those notes also contradict the chart's history. The policy says crossing a Server minor needs at least a chart MINOR bump, and that a PATCH can't change rendered output. But chart 0.2.2 moved to Server 2.10 and changed the default image, and the chart is now 0.2.3 with appVersion 2.10.1.
Additional acceptance:
The deployment guide links the chart upgrade notes.
The chart's versioning either follows its stated policy or the policy text is corrected.
Accepted the additional scope. The site will link the chart upgrade notes and use the published chart/appVersion pair from the existing release metadata in all eight locales.
The next prepared lease release selects Server 2.11.0 / chart 0.3.0, following the chart's stated minor-version policy. Its upgrade notes explicitly acknowledge the historical 0.2.2 exception. Published versions will not be moved or renumbered. This source preparation is not a published or qualified chart; the site's current tuple changes only after actual artifact acceptance.
General verified the current stable manifest's published Server 2.10.1 pairing by anonymously fetching the OCI chart manifest and digest-checked chart layer, rather than inferring it from current main.
This qualifies the metadata pairing for the tuple already selected by the website, not a fresh runtime, cluster-install or newer-Server claim. The website owner may add the chart row/schema/rendering and all-locale guidance without waiting for the separately pending Server 2.11.2 / Helm 0.3.2 artifact qualification. General retains coherent tuple promotion.
Live browser verification compared the full stable-releases.json against source, including both digests and source identity. Sixteen canonical pages pass: all eight compatibility rows/actual localized selection links and all eight pinned deployment commands, chart source/UPGRADING/qualification links, TOCs and nine language alternates. English/Japanese/Chinese 390px light/dark pages were inspected with CJK fonts and no document overflow.
The initial MDX URI-decoding failure remains recorded in PR #378; the documented pre-default remark hook and named URL expansion control passed subsequent all-locale qualification.
Activity
rmcdaniel commentedon Oct 21, 2026
Accepted as a release-metadata documentation improvement. The chart/server pairing already exists in the chart contract; the site needs to expose it from the same machine-owned release data as the other compatibility rows.
Add the exact published chart version and its tested Server appVersion, validate their relationship during the normal documentation build, and explain chart selection and image overrides in the deployment guide. An override is a custom tuple until it receives its own qualification. Apply the guide changes and source hashes in all eight locales. Do not maintain a second handwritten version table.
This follows the active P1 artifact deliveries and can include their exact published Server/chart pair after acceptance. No new runtime capability is required, and no unpublished chart or image is represented as qualified.
rmcdaniel commentedon Oct 21, 2026
Scope addition: the docs site links only the chart source folder, not the chart's upgrade notes, which hold the version policy and per-release migration notes.
Those notes also contradict the chart's history. The policy says crossing a Server minor needs at least a chart MINOR bump, and that a PATCH can't change rendered output. But chart 0.2.2 moved to Server 2.10 and changed the default image, and the chart is now 0.2.3 with
appVersion2.10.1.Additional acceptance:
rmcdaniel commentedon Oct 21, 2026
Accepted the additional scope. The site will link the chart upgrade notes and use the published chart/appVersion pair from the existing release metadata in all eight locales.
The next prepared lease release selects Server 2.11.0 / chart 0.3.0, following the chart's stated minor-version policy. Its upgrade notes explicitly acknowledge the historical 0.2.2 exception. Published versions will not be moved or renumbered. This source preparation is not a published or qualified chart; the site's current tuple changes only after actual artifact acceptance.
rmcdaniel commentedon Oct 23, 2026
General verified the current stable manifest's published Server 2.10.1 pairing by anonymously fetching the OCI chart manifest and digest-checked chart layer, rather than inferring it from current main.
appVersion: 2.10.1, repositoryoci://ghcr.io/durable-workflow/charts/durable-workflow.sha256:ffdb9b8699fae5ffbc9a6723771b38f41dede2940340965605641948eb5e073e. Chart package layersha256:8392a082c368c02ce2120f86ba08c42c2082cbfa8a3ef9b4dbb1e918df9dd45d.d055dc55dcd15c59a64dfc6bc728d154a3197368and imagedocker.io/durableworkflow/server:2.10.1. The immutable Server tag's Chart.yaml agrees. Link its chart upgrade notes.This qualifies the metadata pairing for the tuple already selected by the website, not a fresh runtime, cluster-install or newer-Server claim. The website owner may add the chart row/schema/rendering and all-locale guidance without waiting for the separately pending Server 2.11.2 / Helm 0.3.2 artifact qualification. General retains coherent tuple promotion.
rmcdaniel commentedon Oct 23, 2026
Delivered the existing Server 2.10.1 / Helm chart 0.2.3 pairing in all eight locales through PR #378, merge
d6b2d85441910a781032bb44888242d2757b87b4.Exact-head qualification, artifact publication, and actual Pages deployment pass. The published commit message identifies the exact merged source. All other checks pass; Sonar reports zero new issues after the metadata controls were expressed as three named tests.
Live browser verification compared the full
stable-releases.jsonagainst source, including both digests and source identity. Sixteen canonical pages pass: all eight compatibility rows/actual localized selection links and all eight pinned deployment commands, chart source/UPGRADING/qualification links, TOCs and nine language alternates. English/Japanese/Chinese 390px light/dark pages were inspected with CJK fonts and no document overflow.Compatibility tuple and chart selection/UPGRADING guidance are live. All seven other selected component versions remain unchanged. This ships documentation and metadata for the verified published pairing, with no newer tuple, runtime adoption or fresh cluster-install claim.
The initial MDX URI-decoding failure remains recorded in PR #378; the documented pre-default remark hook and named URL expansion control passed subsequent all-locale qualification.