fix(release-image): stamp stdlib/package.json with release version#23393
Merged
Conversation
The aztec node Docker image was returning "dev" from getNodeVersion in 4.3.0-rc.1. PR #22941 changed getPackageVersion() to read the version from yarn-project/stdlib/package.json instead of .release-please-manifest.json, but release-image/Dockerfile was only updated to stamp the manifest, leaving stdlib/package.json with the "0.1.0" placeholder. That placeholder is treated as a dev checkout and substituted with DEV_VERSION ("dev"). Use jq (already installed in the base image) to write the real version into stdlib/package.json alongside the existing manifest stamp.
alexghr
force-pushed
the
am/stamp-stdlib-package-version
branch
from
af42741 to
75fd494
Compare
alexghr
approved these changes
May 19, 2026
aminsammara
added a commit
that referenced
this pull request
May 20, 2026
Promote v4.3.0-rc.1 to stable. Single commit prepending a `## [4.3.0]` entry to `CHANGELOG.md`; no other files touched. ## What's in this PR The 4.3.0 changelog entry is a superset of the existing `4.3.0-rc.1` entry plus four lines for the commits added between rc.1 and now: - **Bug Fixes** - `aztec:` use perl -i for portable in-place edit in add_crate.sh (#23335) - `aztec-up:` fall back to no timeout when /usr/bin/timeout absent on macOS (#23310) - `release-image:` stamp stdlib/package.json with release version (#23393) - **Miscellaneous** - reduce compat e2e timeout (#23318) The `## [4.3.0-rc.1]` section is preserved below the new entry for historical continuity. ## Filtered from the changelog Eight commits in `v4.3.0-rc.1..HEAD` are dropped as noise: the two `chore: merge v4-next into v4` merge commits, the pre-PR dupe `75fd494a43` of #23393, the two umbrella `chore: Accumulated backports` PRs (#23386, #23321 — their contents are #23310/#23335/#23318 listed above), the internal `Merge branch 'v4-next' into backport-to-v4-next-staging` commit, and the v4-next manifest bump to 4.4.0 (release machinery, doesn't apply to v4). ## After merging 1. Tag `v4.3.0` on the merge commit and push the tag — that kicks off the release pipeline. 2. The manifest stays at `4.3.0` for the 4.3.X patch cycle; bump only if you're cutting 4.4.0 from this branch. ## Test plan - [ ] CI green - [ ] Visual check that the 4.3.0 section reads correctly in `CHANGELOG.md`
critesjosh
added a commit
that referenced
this pull request
May 20, 2026
…or items Backfills v4.3.0 docs with items from the official release notes that weren't carried into the migration notes, framework docs, tutorials, or operator changelog: - migration_notes: add '[CLI] aztec init now scaffolds a Counter example template' under v4.3.0 (#22751). aztec new continues to scaffold blank. - contract_structure: rewrite Directory structure for the 2-crate workspace; drop the stale --name reference removed in v4.3.0. - token_contract tutorial: fix 'aztec init created...' wording to 'aztec new' (the command shown is aztec new bob_token); update live copy from single-crate to 2-crate layout. - recursive_verification tutorial: replace removed 'aztec new --name X Y' with 'aztec new ValueNotEqual'; fix the workspace layout, package name (ValueNotEqual_contract), ccc script, and artifact paths. - v4.3 operator changelog: add 'Other notable changes' for the three non-breaking release-notes items (sequencer last-block signing #22117, stdlib package.json stamping #23393, macOS aztec-up install fixes #23310 / #23335).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The aztec node Docker image was returning
"dev"fromgetNodeVersion()in 4.3.0-rc.1. Root cause: PR #22941 switchedgetPackageVersion()to read the version fromyarn-project/stdlib/package.json, butrelease-image/Dockerfilewas only updated to stamp.release-please-manifest.json(which the old implementation consumed).stdlib/package.jsonkept the0.1.0placeholder inside the image, whichgetPackageVersion()substitutes withDEV_VERSION("dev").This adds a second stamp step in the Dockerfile that rewrites
.versioninyarn-project/stdlib/package.jsonusingjq(already installed in the release-image base). The existing.release-please-manifest.jsonstamp is left alone for now since other tooling may still consume it.Only
stdlib/package.jsonneeds stamping for the version-reporting bug:getPackageVersion()resolves../../package.jsonfromstdlib/dest/update-checker/, so it always reads the stdlib package regardless of which CLI invokes it (aztec --version,getNodeVersion, contract-artifact stamping, etc).The npm publish path is unaffected —
ci3/deploy_npmalready callsci3/release_prep_package_jsonbeforenpm publish, so npm consumers got the correct version all along. The Docker path was the only release surface that missed the rename.Test plan
RUN jq …step.VERSION=4.3.0-rc.Xand confirmaztec --versionand a node'sgetNodeVersionRPC both return the stamped version instead of"dev".