Skip to content

v4.0.0

Choose a tag to compare

@AncientHodler-Demiurg AncientHodler-Demiurg released this 06 May 17:43
· 97 commits to main since this release

fix(monorepo-split): v4.0.0 Phase 6 addendum — smart per-package publish detection

Phase 4's publish.yml hard-coded both npm publish calls and required
BOTH package.json versions to match the tag. That was correct for
v4.0.0 (the monorepo split itself, an atomic dual-publish) but would
become an annoyance starting at v4.1.0: the planned @kadena/client
vendor-and-prune work touches @stoachain/stoa-core only, and forcing
ouronet-core to also bump for an unchanged surface is pointless
co-republishing.

This commit replaces the hard-coded shape with smart per-package
detection:

  • "Detect publish queue" step compares the tag to each package's
    package.json version and emits two outputs (PUBLISH_STOA_CORE,
    PUBLISH_OURONET_CORE).
  • At least one MUST match — otherwise the tag is invalid (typo, or
    doc/version drift), and the workflow fails before npm sees a
    single byte.
  • The README + CHANGELOG version-parity gate now runs only over
    queued packages. A non-published package's docs are untouched
    on a single-package release — they continue to reflect the
    version that IS on npmjs.com for that package.
  • The two npm publish steps are gated by the queue outputs via
    if: conditions. Order preserved: stoa-core first because
    ouronet-core peer-deps it.
  • Each publish step idempotency-checks via npm view first — if
    the version is already on npmjs.com (e.g. pollinate re-runs
    after a partial CI failure), the publish step short-circuits
    instead of erroring out with "version already published".
  • GitHub Release creation runs once per tag regardless of which
    packages it shipped — the annotated-tag message is the
    Release body and covers whichever packages this tag publishes.

Use-case shapes the workflow now handles cleanly

  • Atomic dual-publish (v4.0.0): both packages bump to vX.Y.Z,
    queue lights up both, both publish + their docs gated. The
    behaviour observed pre-this-commit, just routed through the
    detection pipeline.
  • stoa-core-only release (anticipated v4.1.0): bump only
    packages/stoa-core/package.json, leave ouronet-core at the
    previous version, tag vX.Y.Z. Queue lights up stoa-core only;
    ouronet-core's npm publish step short-circuits via the if:
    condition; only stoa-core's README + CHANGELOG is gated for
    v-parity. ouronet-core stays at its previous version on npm.
  • ouronet-core-only release: mirror of the above.

What did NOT change

  • .npmrc writing pattern, --provenance SLSA attestations,
    GitHub Release creation, prior-tag backfill loop — all
    preserved verbatim.
  • ci.yml (PR/push validation) — already handled the workspace
    structure via the root scripts; unchanged.
  • Local pollinate-credentials.md (gitignored) updated separately
    to describe the dual-package setup + lifecycle config block
    pointing pollinate's primary-package field at
    packages/ouronet-core/.

Verification

This commit only modifies a CI workflow — no source/test/build delta.
Phase 5's verification gates (typecheck/test/build all green; 703/703
passing) carry through unchanged. Smart-detection logic verified
locally by simulating the bash steps against the current package.json
versions: tag=4.0.0 → queue=[stoa-core, ouronet-core], the atomic case.

Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com