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
docs: docker-compose.yml comment examples still reference v0.6.0 #235
Current release is v0.7.3 per CHANGELOG.md, so these examples are stale. Not a functional bug since the variables are required and have no default, but someone copy-pasting the example value would end up on an old, no-longer-compatible image. Happy to send a small PR updating the two lines.
Confirmed against main: the two header-comment examples in deployments/docker-compose.yml are the only 0.6.0 references left under deployments/ (repo-wide code search), and the compose file itself is safely version-free — every image reference is ${ARC_EXECUTION_IMAGE:?...} / ${ARC_CONSENSUS_IMAGE:?...} with a required-variable guard, so the stale values live purely in prose. Your severity call is right: not a functional bug, but these are exactly the strings someone copy-pastes into their shell, and a 0.6.0 image has been unable to follow testnet since the Zero5/Zero6 activation on 2026-05-27 (see #225 for the same class of staleness in installation.md, fixed in #226). The resulting failure mode is nasty for the person who hits it: the compose stack starts cleanly, downloads ~84 GB of snapshots per the file's own comment, and only then fails to sync — with nothing pointing back at the image tag.
Suggestion for the PR you offered — don't just bump the tag; borrow the pattern from the doc this comment already cites. The header points at docs/running-an-arc-node.md#docker, and that doc's own examples are version-free:
If the compose header's examples use :$ARC_VERSION (or :<version> with a "see the Versions table / BREAKING_CHANGES.md" pointer) instead of a literal tag, this file exits the class of docs that go stale on every release — updating to 0.7.3 today re-arms the same bug for v0.8.0. That's not hypothetical for this repo: #225/#226 just fixed the identical pattern in installation.md, and this file was missed there because the search that drove #226 targeted v0.6.0 with the v prefix while these comments spell it 0.6.0 bare (worth remembering for whoever does the next audit — the Docker tags drop the v).
If maintainers prefer keeping a concrete copy-pasteable value in the comment (legitimate — required-but-undefaulted variables with abstract examples annoy people too), the compromise is a literal tag plus the pointer: arc-execution:0.7.3 today, with "check the Versions table in docs/installation.md for the current tag" on the same line, so a stale example at least carries its own correction path.
Either way the change stays a two-line comment edit — happy to review the PR when it's up.
Good catch on the v prefix gap — that's exactly the kind of thing that'll bite the next audit too. Went with the $ARC_VERSION pattern from running-an-arc-node.md rather than the literal-plus-pointer compromise, since the file already points there and it keeps both docs consistent. Updated #238.
Right call — consistency with running-an-arc-node.md was the strongest argument for that option, and it means both files now describe the same workflow in the same vocabulary. I've reviewed and approved #238; the diff is correct and clears the last 0.6.0 references under deployments/.
One loose end noted in the review, repeating here since it affects how this issue closes: the PR title/body still say "updated to v0.7.3", but the diff you actually (rightly) shipped contains no 0.7.3 — it's the $ARC_VERSION substitution. Worth retitling before merge so the commit history says what happened; otherwise the next staleness audit may skip this file believing it pins a current tag, which is the exact failure mode that left these comments stale for three releases.
With #238 merged this issue closes cleanly — and between #226 (installation.md) and #238, the only remaining member of this staleness class repo-wide is whatever new doc introduces the next hardcoded tag. The audit note for whoever does that sweep: grep both v0.6.0-style and bare 0.6.0-style spellings; docs use the prefix, Docker tags drop it.
Thanks for the approval. The retitle/body fix should already be visible on #238 — updated it to 'docs: use $ARC_VERSION in docker-compose.yml image comments' with a body describing the actual diff, right after your first comment (might have crossed with your review). Also added the Versions table pointer inline for readers who open the compose file directly. Good note on the grep pattern for the next audit — v-prefixed in docs, bare in Docker tags.
Activity
osr21 commentedon Aug 8, 2026
Confirmed against
main: the two header-comment examples indeployments/docker-compose.ymlare the only0.6.0references left underdeployments/(repo-wide code search), and the compose file itself is safely version-free — every image reference is${ARC_EXECUTION_IMAGE:?...}/${ARC_CONSENSUS_IMAGE:?...}with a required-variable guard, so the stale values live purely in prose. Your severity call is right: not a functional bug, but these are exactly the strings someone copy-pastes into their shell, and a0.6.0image has been unable to follow testnet since the Zero5/Zero6 activation on 2026-05-27 (see #225 for the same class of staleness ininstallation.md, fixed in #226). The resulting failure mode is nasty for the person who hits it: the compose stack starts cleanly, downloads ~84 GB of snapshots per the file's own comment, and only then fails to sync — with nothing pointing back at the image tag.Suggestion for the PR you offered — don't just bump the tag; borrow the pattern from the doc this comment already cites. The header points at
docs/running-an-arc-node.md#docker, and that doc's own examples are version-free:If the compose header's examples use
:$ARC_VERSION(or:<version>with a "see the Versions table / BREAKING_CHANGES.md" pointer) instead of a literal tag, this file exits the class of docs that go stale on every release — updating to0.7.3today re-arms the same bug for v0.8.0. That's not hypothetical for this repo: #225/#226 just fixed the identical pattern ininstallation.md, and this file was missed there because the search that drove #226 targetedv0.6.0with thevprefix while these comments spell it0.6.0bare (worth remembering for whoever does the next audit — the Docker tags drop thev).If maintainers prefer keeping a concrete copy-pasteable value in the comment (legitimate — required-but-undefaulted variables with abstract examples annoy people too), the compromise is a literal tag plus the pointer:
arc-execution:0.7.3today, with "check the Versions table in docs/installation.md for the current tag" on the same line, so a stale example at least carries its own correction path.Either way the change stays a two-line comment edit — happy to review the PR when it's up.
teyrebaz33 commentedon Aug 8, 2026
Good catch on the
vprefix gap — that's exactly the kind of thing that'll bite the next audit too. Went with the $ARC_VERSION pattern from running-an-arc-node.md rather than the literal-plus-pointer compromise, since the file already points there and it keeps both docs consistent. Updated #238.osr21 commentedon Aug 8, 2026
Right call — consistency with
running-an-arc-node.mdwas the strongest argument for that option, and it means both files now describe the same workflow in the same vocabulary. I've reviewed and approved #238; the diff is correct and clears the last0.6.0references underdeployments/.One loose end noted in the review, repeating here since it affects how this issue closes: the PR title/body still say "updated to v0.7.3", but the diff you actually (rightly) shipped contains no
0.7.3— it's the$ARC_VERSIONsubstitution. Worth retitling before merge so the commit history says what happened; otherwise the next staleness audit may skip this file believing it pins a current tag, which is the exact failure mode that left these comments stale for three releases.With #238 merged this issue closes cleanly — and between #226 (installation.md) and #238, the only remaining member of this staleness class repo-wide is whatever new doc introduces the next hardcoded tag. The audit note for whoever does that sweep: grep both
v0.6.0-style and bare0.6.0-style spellings; docs use the prefix, Docker tags drop it.docs: use $ARC_VERSION in docker-compose.yml image comments
teyrebaz33 commentedon Aug 8, 2026
Thanks for the approval. The retitle/body fix should already be visible on #238 — updated it to 'docs: use $ARC_VERSION in docker-compose.yml image comments' with a body describing the actual diff, right after your first comment (might have crossed with your review). Also added the Versions table pointer inline for readers who open the compose file directly. Good note on the grep pattern for the next audit — v-prefixed in docs, bare in Docker tags.
docs: use $ARC_VERSION in docker-compose.yml image comments (#238)