release: scope the version bump to publishable packages, not the name glob - #1094
Conversation
… glob The version-bump command used --filter "@fundamental-engine/*", which also matches the private workspace apps (apps/site, apps/starter, apps/observatory). They share the npm scope but version independently, and 'exec npm version' ignores the private flag — so the glob silently bumped all three to the release version. 0.10.0 caught it in the act: observatory went 0.0.0 -> 0.10.0 and had to be reverted by hand mid-release. The doc already knew: it carried a note to 'revert them after the bump' with a git checkout list. That mitigation is exactly the step that's easy to forget. Prevention beats it — the path filter ./packages/* targets only the seven publishable packages, so nothing is bumped that shouldn't be and there is nothing to revert. Its confirm line already used ./packages/*; this finishes a half-done migration. pnpm publish already skips private packages, so only the version bump was ever affected; the publish commands are changed to ./packages/* for consistency, same seven packages. Applied across RELEASING.md, PUBLISHING.md and release.yml. check:links green; release.yml YAML validated; ./packages/* confirmed to resolve to exactly the seven.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1a89a9940d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| 3. **Bump all seven packages together** (keep them at the same version): | ||
| ```sh | ||
| pnpm --filter "@fundamental-engine/*" exec npm version <patch|minor|major> --no-git-tag-version | ||
| pnpm --filter "./packages/*" exec npm version <patch|minor|major> --no-git-tag-version |
There was a problem hiding this comment.
When this new path selector is run from any subdirectory (for example packages/core while cutting a release), pnpm interprets ./packages/* relative to the current working directory; pnpm help publish describes --filter ./<dir> as selecting packages inside that subdirectory, and --fail-if-no-match is the separate opt-in for failing on no matches. I verified with pnpm 10.28.1 that from packages/core this selector prints No projects matched and exits 0, so the version-bump step can silently skip all seven packages; the old name glob was cwd-independent. Please either state that these commands must be run from the repo root, add --fail-if-no-match, or use exact package-name filters.
Useful? React with 👍 / 👎.
Kotlin port parity — the Compose `FieldView` renders a multi-hue palette. Resolves #1090; ships the fix merged in #1095. ## What & scope - `FieldView` gains `palette: List<Color>` (backward-compatible; defaults to `[accent]`). Each particle takes a stable colour by pool index across all four render modes. Verified against the iOS `10-intro-star`. - **Kotlin-only.** JS and Swift are byte-identical to 0.10.0 — they already had the palette. npm + Swift republish at 0.10.1 **only** to hold cross-plane lockstep; no JS/Swift behaviour change. The changelog states this so the bump isn't misread. ## Versions - 7 packages + `FIELD_VERSION` → `0.10.1` (lockstep, drift test green). - **The private-app trap did not recur** — the `./packages/*` filter from #1094 held: site/starter/observatory unchanged at 0.2.0 / 0.1.0 / 0.0.0. ## Release `git tag v0.10.1` → npm + Swift (SPM) + Kotlin (Maven, via the CI job) in lockstep. Ascent then flips `0.10.1-local` → `0.10.1`. ## Still open #1091 — the parity matrix doesn't track colour, which is why this reached an app before a gate. Closing it makes a future palette divergence fail CI instead of shipping. ## Gates typecheck · build · `check:api` (no removals) · `check:docs` · `check:links` · FIELD_VERSION lockstep — all green.
1 participant
The bug 0.10.0 caught
The release version-bump used
pnpm --filter "@fundamental-engine/*" exec npm version …. That glob also matches the private workspace apps —apps/site,apps/starter,apps/observatory— which share the npm scope but version independently.exec npm versionignores theprivateflag, so the glob silently bumped all three to the release version.Live proof: during 0.10.0,
observatoryjumped0.0.0 → 0.10.0and I had to revert it by hand mid-release.Why prevention, not the existing mitigation
RELEASING.mdalready carried a note to "revert them after the bump" with agit checkoutlist. That manual revert is exactly the step that's easy to forget — and forgetting it ships wrong app versions.The fix removes the failure mode instead of documenting around it:
./packages/*resolves to exactly the seven — verified — so nothing bumps that shouldn't, and the revert step is deleted as dead.Scope
RELEASING.md,PUBLISHING.md,release.yml(8 occurrences). Publish commands changed too for consistency — behaviorally identical, sincepnpm publishalready skips private packages (which is why only the bump was ever affected).Gates
check:linksgreen ·release.ymlYAML validated ·./packages/*confirmed = 7 packages.