chore(release): prepare 0.2.1 #85

Merged
Zayin_Admin merged 1 commits from chore/release-0.2.1 into main 2026-10-09 03:01:00 +00:00
Member

Prepares the coordinated 0.2.1 release: the version-set step of docs/development/releases.md. Nothing is published or tagged.

Why 0.2.1, a patch

Since v0.2.0 (1788d17), main has exactly one change: #84.

  • It adds the reviewed @img/[email protected] supplement and moves the native proof to sharp 0.35.5.
  • That is new packager data plus test-only dependencies.
  • No module SDK, manifest, database ABI, packageFormat or package API changed.

Under the release guide, a breaking change before 1.0 needs a minor version, and a patch changes no compatibility range. So 0.2.1 is the correct release. (The publication path fix, #83, is already inside v0.2.0.)

Version set (16 files)

  • 0.2.1 in every platform workspace package (14 files):
    • the root package.json, apps/api, core, surfaces/shell;
    • packages/{contracts, design-tokens, module-database, module-pack, module-sdk, module-ui-build, module-ui-host, module-ui-sdk, typescript-config, ui}.
  • deploy/README.md: the image build example now names 0.2.1.
  • tests/fixtures/standalone-module/package.json: the @ekklesia/* ranges become ^0.2.1, and @ekklesia/module-pack is pinned exactly to 0.2.1 (ADR 0053). The fixture consumes exactly this release's train.
  • Unchanged:
    • templates/module and the fixture modules keep their own versions;
    • pnpm-lock.yaml is unchanged, because workspace packages are links.

Compatibility ranges: unchanged at ^0.2.0, on purpose

A package dependency range and a module compatibility range are different decisions:

  • The fixture's package ranges follow the train it consumes (^0.2.1), as at every release.
  • compatibility.platform and compatibility.moduleSdk state which platforms a module runs on. 0.2.1 is compatible with 0.2.0, so the template, the standalone fixture, the native proof module, the test fixtures that model the current platform, and the guide's examples all stay at ^0.2.0.
  • A module built for 0.2.0 keeps working on 0.2.1. As a check, Core's verifier at this commit accepted a ^0.2.0 package against platform and SDK version 0.2.1.

The 0.2.1 train (strict scripts/test-package-release.sh, clean tree, revision 6e76293)

  • All nine packages are at 0.2.1: contracts, design-tokens, module-database, module-pack, module-sdk, module-ui-build, module-ui-sdk, typescript-config, ui.
  • Internal dependencies are exactly 0.2.1: module-database, module-sdk and module-ui-build → contracts; ui → design-tokens; module-pack → contracts and module-ui-build. No workspace: range survives packing.
  • Reproducible: the second build is byte-identical (11 files: the nine tarballs, SHA256SUMS, and the manifest). The manifest says modified: false.
  • The standalone consumer proof passed: an offline install from the tarballs, a frozen reinstall with lockfile integrity checks, skipLibCheck: false typecheck, build, a package made with the release's module-pack, and the platform verifier.

module-pack 0.2.1 contents

  • Both reviewed supplements ship. @img/sharp-libvips-linux-x64/1.3.3/ has 143 texts plus supplement.json and PROVENANCE.md; 1.3.4/ has 146 plus the same two. That's 333 tarball entries, against the published 0.2.0's 185.
  • Nothing dev-only: no tests, fixtures or TypeScript sources.
  • The packed manifest has no devDependencies, so the test-only sharp-0.35.4 alias can't reach a consumer. Its dependencies are @ekklesia/contracts 0.2.1, @ekklesia/module-ui-build 0.2.1, esbuild 0.28.1 and semver 7.8.5.

Native proof (sharp 0.35.5, libvips 1.3.4)

  • Workspace tests: module-pack's native, closure and supplement tests pass, 31 of 31, with the native suite actually run on a linux-x64-glibc host.
  • The released artifact itself:
    • I installed the proof module outside the repository with module-pack-0.2.1.tgz from the release directory and sharp 0.35.5, and ran ekklesia-pack-module --target linux-x64-glibc;
    • the result is native-proof-0.1.0-linux-x64-glibc.tar.gz (125 files), and its THIRD_PARTY_NOTICES merges the reviewed 1.3.4 supplement by digest 2927fe11…5e59;
    • its runtime is Node-API 9, glibc >= 2.28.0;
    • Core's verifyModulePackage at this commit accepts it;
    • sharp runs from the extracted copy in an empty environment, with the expected resize and PNG round-trip results.

Verification

  • pnpm verify: passes (all workspace test suites, including Core's 54 files and module-pack's 6).
  • pnpm test:migrations:integration: 15 files and 396 tests pass (release step 2).
  • The deploy smoke runs in CI.

After merge (not done here)

  1. Dispatch Publish packages on the merge commit, with version 0.2.1.
  2. The maintainer tags v0.2.1 on that merge commit.
  3. Then Signage's native-package PR moves to @ekklesia/module-pack 0.2.1, sharp 0.35.5, ^0.2.1 ranges, and the matching release-age exemptions.

🤖 Generated with Claude Code

Prepares the coordinated **0.2.1** release: the version-set step of `docs/development/releases.md`. Nothing is published or tagged. ## Why 0.2.1, a patch Since `v0.2.0` (`1788d17`), main has exactly one change: **#84**. - It adds the reviewed `@img/[email protected]` supplement and moves the native proof to sharp 0.35.5. - That is new packager data plus test-only dependencies. - No module SDK, manifest, database ABI, `packageFormat` or package API changed. Under the release guide, a breaking change before 1.0 needs a minor version, and a patch changes no compatibility range. So 0.2.1 is the correct release. (The publication path fix, #83, is already inside v0.2.0.) ## Version set (16 files) - **0.2.1 in every platform workspace package (14 files):** - the root `package.json`, `apps/api`, `core`, `surfaces/shell`; - `packages/{contracts, design-tokens, module-database, module-pack, module-sdk, module-ui-build, module-ui-host, module-ui-sdk, typescript-config, ui}`. - **`deploy/README.md`:** the image build example now names 0.2.1. - **`tests/fixtures/standalone-module/package.json`:** the `@ekklesia/*` ranges become `^0.2.1`, and `@ekklesia/module-pack` is pinned exactly to `0.2.1` (ADR 0053). The fixture consumes exactly this release's train. - **Unchanged:** - `templates/module` and the fixture modules keep their own versions; - `pnpm-lock.yaml` is unchanged, because workspace packages are links. ## Compatibility ranges: unchanged at `^0.2.0`, on purpose A package dependency range and a module compatibility range are different decisions: - **The fixture's package ranges** follow the train it consumes (`^0.2.1`), as at every release. - **`compatibility.platform` and `compatibility.moduleSdk`** state which platforms a module runs on. 0.2.1 is compatible with 0.2.0, so the template, the standalone fixture, the native proof module, the test fixtures that model the current platform, and the guide's examples all stay at `^0.2.0`. - A module built for 0.2.0 keeps working on 0.2.1. As a check, Core's verifier at this commit accepted a `^0.2.0` package against platform and SDK version 0.2.1. ## The 0.2.1 train (strict `scripts/test-package-release.sh`, clean tree, revision `6e76293`) - **All nine packages are at 0.2.1:** contracts, design-tokens, module-database, module-pack, module-sdk, module-ui-build, module-ui-sdk, typescript-config, ui. - **Internal dependencies are exactly 0.2.1:** module-database, module-sdk and module-ui-build → contracts; ui → design-tokens; module-pack → contracts and module-ui-build. No `workspace:` range survives packing. - **Reproducible:** the second build is byte-identical (11 files: the nine tarballs, `SHA256SUMS`, and the manifest). The manifest says `modified: false`. - **The standalone consumer proof passed:** an offline install from the tarballs, a frozen reinstall with lockfile integrity checks, `skipLibCheck: false` typecheck, build, a package made with the release's module-pack, and the platform verifier. ### module-pack 0.2.1 contents - **Both reviewed supplements ship.** `@img/sharp-libvips-linux-x64/1.3.3/` has 143 texts plus `supplement.json` and `PROVENANCE.md`; `1.3.4/` has 146 plus the same two. That's 333 tarball entries, against the published 0.2.0's 185. - **Nothing dev-only:** no tests, fixtures or TypeScript sources. - **The packed manifest has no `devDependencies`,** so the test-only `sharp-0.35.4` alias can't reach a consumer. Its dependencies are `@ekklesia/contracts` 0.2.1, `@ekklesia/module-ui-build` 0.2.1, `esbuild` 0.28.1 and `semver` 7.8.5. ## Native proof (sharp 0.35.5, libvips 1.3.4) - **Workspace tests:** module-pack's native, closure and supplement tests pass, 31 of 31, with the native suite actually run on a linux-x64-glibc host. - **The released artifact itself:** - I installed the proof module outside the repository with `module-pack-0.2.1.tgz` from the release directory and sharp 0.35.5, and ran `ekklesia-pack-module --target linux-x64-glibc`; - the result is `native-proof-0.1.0-linux-x64-glibc.tar.gz` (125 files), and its `THIRD_PARTY_NOTICES` merges the reviewed 1.3.4 supplement by digest `2927fe11…5e59`; - its runtime is Node-API 9, glibc >= 2.28.0; - Core's `verifyModulePackage` at this commit accepts it; - sharp runs from the extracted copy in an empty environment, with the expected resize and PNG round-trip results. ## Verification - `pnpm verify`: passes (all workspace test suites, including Core's 54 files and module-pack's 6). - `pnpm test:migrations:integration`: 15 files and 396 tests pass (release step 2). - The deploy smoke runs in CI. ## After merge (not done here) 1. Dispatch **Publish packages** on the merge commit, with version `0.2.1`. 2. The maintainer tags `v0.2.1` on that merge commit. 3. Then Signage's native-package PR moves to `@ekklesia/module-pack` `0.2.1`, sharp `0.35.5`, `^0.2.1` ranges, and the matching release-age exemptions. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
ekklesia-bot added 1 commit 2026-10-09 02:50:08 +00:00
chore(release): prepare 0.2.1
CI / verify (pull_request) Successful in 1m8s
CI / infrastructure-smoke (pull_request) Successful in 38s
CI / migration-smoke (pull_request) Successful in 1m57s
CI / package-release (pull_request) Successful in 36s
CI / image-build (pull_request) Successful in 31s
CI / deploy-smoke (same-origin) (pull_request) Successful in 55s
CI / deploy-smoke (split) (pull_request) Successful in 1m30s
CI / package-publication (pull_request) Successful in 52s
6e76293620
Every platform workspace package and every public @ekklesia/* package declares 0.2.1, and the deploy
README's image build example names it. templates/module and the fixture modules keep their own
versions.

0.2.1, a patch: since v0.2.0 (1788d17), main has one change, #84. It adds the reviewed supplement for
@img/[email protected] and moves the packager's native proof to sharp 0.35.5. That is new
packager data and test-only dependencies. No SDK, manifest, database ABI, packageFormat, or package
API changed.

The standalone fixture consumes exactly this release: its @ekklesia ranges become ^0.2.1 and its
module-pack pin 0.2.1 (docs/development/releases.md, step 1). Module compatibility ranges stay ^0.2.0,
as the release guide says a patch version requires. The template, the standalone fixture, the native
proof module, and the test fixtures modelling the current platform are therefore unchanged. A module
built for 0.2.0 remains compatible with 0.2.1.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Zayin_Admin merged commit 4919db6168 into main 2026-10-09 03:01:00 +00:00
Zayin_Admin deleted branch chore/release-0.2.1 2026-10-09 03:01:00 +00:00
Sign in to join this conversation.
No Reviewers
No labels
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Zayin/Ekklesia#85