Zayin/Ekklesia
3
0
Fork 0
Code Issues 1 Pull Requests 3 Actions 1 Packages Projects Releases 8 Wiki Activity

chore(release): prepare 0.2.0 #82

Merged
Zayin_Admin merged 1 commits from chore/release-0.2.0 into main 2026-10-08 22:36:19 +00:00
Conversation 1 Commits 1 Files Changed 33
+85 -77
ekklesia-bot commented 2026-10-08 22:28:17 +00:00
Member
Copy Link
Copy Source

Prepares platform release 0.2.0, the first release whose public @ekklesia/* package train will be published. Nothing is published, and no tag is created by this PR.

Why 0.2.0, not 0.1.3

Before 1.0, a minor version is the breaking one: "a 0.x minor version may break them" (docs/development/releases.md, cited by ADR 0054). npm's caret ranges (^0.1.x) treat 0.x minors the same way. Since v0.1.2, main has broken modules, module authors and operators:

  • #64 (ADR 0048): one generic image; installed modules live outside it.
  • #66, #72 (ADR 0049, 0050): modules install as Module Package v1 and move to the Module Database ABI.
  • #71: the manifest v8 cutover; v7 manifests are refused.
  • #79 (ADR 0053): the curated SDK drops defineModuleSchema and the legacy ModuleDatabase type.

Also in this range: AGPL licensing (#67), license material and native targets (#74, #77), and the public package train (#80, #81). 0.1.3 would wrongly signal compatibility, and ^0.1.x consumers would pick these changes up automatically.

What changes

Following the 0.1.2 release-preparation convention (chore(release): prepare 0.1.2):

  • Version 0.2.0:
    • the root package.json;
    • apps/api, core, surfaces/shell;
    • every package under packages/: the nine public @ekklesia/* packages, plus the private module-ui-host.
  • templates/module keeps its own version (0.1.0).
  • deploy/README.md: the image build example.

Because 0.2.0 is outside ^0.1.0, the same change moves to ^0.2.0 in:

  • The standalone fixture's dependencies: its @ekklesia/* ranges and its exact @ekklesia/module-pack pin, as ADR 0053 requires.

  • The compatibility ranges of modules built for this release:

    • the template;
    • the standalone fixture;
    • the native proof module.

    Without this, the packager correctly refuses to bundle SDK 0.2.0 into a module that declares moduleSdk: ^0.1.0.

  • Test fixtures that model a module of the current release, or the current platform's versions. Fixtures that are deliberately incompatible, module-to-module dependency ranges, and synthetic fixtures not tied to the platform version are unchanged.

  • The module-development guide's examples. docs/development/releases.md now also says exactly what a minor bump must move.

Evidence

  • pnpm verify passes (2,585 tests).
  • pnpm test:migrations:integration passes (396 tests): the live API discovers the fixture modules against 0.2.0.
  • pnpm test:package-release passes, strict:
    • nine tarballs, all 0.2.0, every @ekklesia dependency exactly 0.2.0;
    • built from a clean commit;
    • the two builds byte-identical;
    • the standalone consumer proof passes against the 0.2.0 train.
  • pnpm test:package-publication: that exact 0.2.0 train published to a disposable Gitea, 10 of 10.
  • The real registry: an anonymous search returns {"objects":[],"total":0}, and every @ekklesia/* lookup is 404. No v* tag beyond v0.1.2 exists.

After merge

  1. A maintainer runs Actions → Publish packages on main, at this PR's merge commit, with version 0.2.0.
  2. Check the run's package-train-publication-record artifact: nine packages, latest 0.2.0.
  3. The maintainer tags the same merge commit v0.2.0, as current release policy requires.

🤖 Generated with Claude Code

Prepares platform release **0.2.0**, the first release whose public `@ekklesia/*` package train will be published. **Nothing is published, and no tag is created** by this PR. ## Why 0.2.0, not 0.1.3 Before 1.0, a **minor** version is the breaking one: "a 0.x minor version may break them" (`docs/development/releases.md`, cited by ADR 0054). npm's caret ranges (`^0.1.x`) treat 0.x minors the same way. Since `v0.1.2`, `main` has broken modules, module authors and operators: - **#64 (ADR 0048):** one generic image; installed modules live outside it. - **#66, #72 (ADR 0049, 0050):** modules install as Module Package v1 and move to the Module Database ABI. - **#71:** the manifest v8 cutover; v7 manifests are refused. - **#79 (ADR 0053):** the curated SDK drops `defineModuleSchema` and the legacy `ModuleDatabase` type. Also in this range: AGPL licensing (#67), license material and native targets (#74, #77), and the public package train (#80, #81). 0.1.3 would wrongly signal compatibility, and `^0.1.x` consumers would pick these changes up automatically. ## What changes Following the 0.1.2 release-preparation convention (`chore(release): prepare 0.1.2`): - **Version 0.2.0:** - the root `package.json`; - `apps/api`, `core`, `surfaces/shell`; - every package under `packages/`: the nine public `@ekklesia/*` packages, plus the private `module-ui-host`. - **`templates/module` keeps its own version** (0.1.0). - **`deploy/README.md`:** the image build example. Because 0.2.0 is outside `^0.1.0`, the same change moves to `^0.2.0` in: - **The standalone fixture's dependencies:** its `@ekklesia/*` ranges and its exact `@ekklesia/module-pack` pin, as ADR 0053 requires. - **The compatibility ranges of modules built for this release:** - the template; - the standalone fixture; - the native proof module. Without this, the packager correctly refuses to bundle SDK 0.2.0 into a module that declares `moduleSdk: ^0.1.0`. - **Test fixtures that model a module of the current release, or the current platform's versions.** Fixtures that are deliberately incompatible, module-to-module dependency ranges, and synthetic fixtures not tied to the platform version are unchanged. - **The module-development guide's examples.** `docs/development/releases.md` now also says exactly what a minor bump must move. ## Evidence - **`pnpm verify`** passes (2,585 tests). - **`pnpm test:migrations:integration`** passes (396 tests): the live API discovers the fixture modules against 0.2.0. - **`pnpm test:package-release`** passes, strict: - nine tarballs, all 0.2.0, every `@ekklesia` dependency exactly 0.2.0; - built from a clean commit; - the two builds byte-identical; - the standalone consumer proof passes against the 0.2.0 train. - **`pnpm test:package-publication`:** that exact 0.2.0 train published to a disposable Gitea, 10 of 10. - **The real registry:** an anonymous search returns `{"objects":[],"total":0}`, and every `@ekklesia/*` lookup is 404. No `v*` tag beyond `v0.1.2` exists. ## After merge 1. A maintainer runs **Actions → Publish packages** on `main`, at this PR's merge commit, with version `0.2.0`. 2. Check the run's `package-train-publication-record` artifact: nine packages, `latest` 0.2.0. 3. The maintainer tags the same merge commit `v0.2.0`, as current release policy requires. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
ekklesia-bot added 1 commit 2026-10-08 22:28:18 +00:00
chore(release): prepare 0.2.0
CI / verify (pull_request) Successful in 1m5s
Details
CI / infrastructure-smoke (pull_request) Successful in 35s
Details
CI / migration-smoke (pull_request) Successful in 1m52s
Details
CI / package-release (pull_request) Successful in 35s
Details
CI / image-build (pull_request) Successful in 31s
Details
CI / deploy-smoke (same-origin) (pull_request) Successful in 45s
Details
CI / deploy-smoke (split) (pull_request) Successful in 1m30s
Details
CI / package-publication (pull_request) Successful in 44s
Details
98e59d4ba0 
Every platform workspace package and every public @ekklesia/* package
declares 0.2.0, and the deploy README's image build example names it.
templates/module keeps its own version.

0.2.0, not 0.1.3: before 1.0 a minor version is the breaking one
(docs/development/releases.md, ADR 0054), and since 0.1.2 main has
broken modules, module authors, and operators:
- #64 (ADR 0048): one generic image; installed modules live outside it;
- #66, #72 (ADR 0049, 0050): modules install as Module Package v1, and
  move to the Module Database ABI;
- #71: the manifest v8 cutover; v7 manifests are refused;
- #79 (ADR 0053): the curated SDK drops defineModuleSchema and the
  legacy ModuleDatabase type;
plus #67 (AGPL), #74, #77 (licensing, native targets), and the public
package train (#80, #81). It is also the first package train to publish:
0.1.2 never will be.

Because 0.2.0 is outside ^0.1.0, the same change moves to ^0.2.0:
- the standalone fixture's @ekklesia ranges and its exact module-pack pin;
- the compatibility ranges of the modules built for this release: the
  template, the standalone fixture, and the native proof module;
- the test fixtures that model a module of the current release, or the
  current platform's versions;
- the module-development guide's examples, and the release guide, which
  now names what a minor bump moves.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Zayin_Admin merged commit debb8df3ce into main 2026-10-08 22:36:19 +00:00
Zayin_Admin deleted branch chore/release-0.2.0 2026-10-08 22:36:19 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Zayin_Admin
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
Joey Zayin_Admin ekklesia-bot
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Zayin/Ekklesia#82