Skip to content

chore: release 1.3.0 across npm, PyPI, NuGet and Maven Central - #556

Merged
dmealing merged 2 commits into
mainfrom
fm/mo-release-1-3-0
Nov 12, 2026
Merged

dmealing merged 2 commits into
mainfrom
fm/mo-release-1-3-0

Conversation

@dmealing

Copy link
Copy Markdown
Member

What Changed

  • Bumps every publishable package to 1.3.0: the 14 @metaobjectsdev/* npm packages and the React, runtime-web and TanStack client packages, plus the Python pyproject.toml/uv.lock, the C# Directory.Build.props and the Java reactor and module POMs (Maven 8.3.0). bun.lock is regenerated to match.
  • Adds the ## [1.3.0] — 2026-11-11 CHANGELOG section with an "Upgrading from 1.2.0" list. It covers the metamodelVersion move to 1.3, the breaking C# naming-strategy change, and the deprecation of tsOnly in favor of implementedIn.
  • Updates the @sequenceStart wording in docs/CONFORMANCE.md, docs/features/migrations-and-drift.md and docs/ports/csharp.md: in 1.3.0 the existing counter is not moved, and a later release is planned to move a counter below the declared start forward. Also refreshes the docs/llms files and the showcase site-payload.json registry versions.
Validation

Risk Assessment

✅ Low: Mechanical lockstep version bump (npm/PyPI/NuGet 1.3.0, Maven 8.3.0) plus a changelog promotion that describes @sequenceStart as not moving an existing counter in 1.3.0 without promising it forever, matching the stated rulings; only stale public-facing version prose remains.

Testing

Target commit changes only version strings, CHANGELOG, docs and bun.lock; no product behavior differs from base. Scenarios focused on the A5 unknown-variable guard, driven live through the TS render engine with synthetic inputs. Version-number consistency was checked by reading manifests only and is recorded as untested for live purposes. Python Mustache-helper path and full five-port A5 conformance were not driven. Probe script removed; worktree clean.

  • Live validation: ✅ go - 3 of 5 scenarios driven live against the product
Scenario Result Live Evidence
Release version 1.3.0 (npm/PyPI/NuGet) and 8.3.0 (Maven) consistent across all manifests ⏸️ untested no Only a manifest grep was run; no live product run was driven for this scenario, so the prior pass is not supported.
Unknown template variable raises on generated render path (verify payload tree passed) ✅ pass live bun probe of render() in server/typescript/packages/render/src/index.ts: 'Hello {{nmae}}' with verify tree threw ERR_VAR_NOT_ON_PAYLOAD (nmae)
Known template variable still renders on the same path ✅ pass live bun probe: 'Hello {{name}}' => 'Hello Ada' with and without verify tree
Unknown template variable without payload tree (inline render) ✅ pass live bun probe: 'Hello {{nmae}}' rendered 'Hello ' with no verify option
Python Mustache-helper unknown-variable path ⏸️ untested no Not exercised; it is in the base commit, not this diff. Would need a Python render run in a disposable uv env; not done within this step's scope.
  • Outcome: ⚠️ 1 info across 1 run (16m18s)

Pipeline

Updates from git push no-mistakes

✅ **Intent** - passed

✅ No issues found.

✅ **Rebase** - passed

✅ No issues found.

⚠️ **Review** - 2 infos
  • ℹ️ README.md:163 - Version-bearing prose still reads 1.2.0 / 8.2.0 after the bump: README.md:163-167 (port table), server/java/README.md:3 and :28, AGENTS.md:42-44 and :83 ("Where the versions are"), and the fit-assessment capability sheet (agent-context/skills/metaobjects-fit-assessment/SKILL.md:11,461 and references/capability-sheet.md:1). The llms mirrors and site-payload were restamped. Prior release 1.2.0 restamped these in follow-up PRs (feat(python): add pydantic extra and restamp docs to 1.2.0 #513, docs(agent-context): bring fit-assessment capability sheet up to 1.2.0 #514) after the registry publish, so this may be intentional, but the README is the public front page and goes stale once 1.3.0 is published. Restamp after publish, or confirm that is the plan.
  • ℹ️ bun.lock:474 - bun.lock regeneration also bumped unrelated transitive deps beyond the workspace version lines (@babel/core 7.29.7 to 7.29.13, @babel/generator, @babel/parser, @babel/traverse, @inquirer/*, @electric-sql/pglite, and others). Not a workspace-version change; it widens the release diff and ships whatever those resolved to. Acceptable if the lockfile was regenerated deliberately per RELEASING.md and the full ci-local run (A2) is green on this SHA; flagging so it is a conscious choice.
⚠️ **Test** - 1 info
  • ℹ️ CHANGELOG 1.3.0 says a template naming a variable not on its payload 'now raises at render time'. Live probe: render() raises ERR_VAR_NOT_ON_PAYLOAD only when a payload field tree is passed (verify option, which generated prompt render functions always pass). Inline render without the tree still renders the unknown variable as empty. Wording is accurate for generated paths; consider naming that in the upgrade note.
  • Live validation: ✅ go - 3 of 5 scenarios driven live against the product
Scenario Result Live Evidence
Release version 1.3.0 (npm/PyPI/NuGet) and 8.3.0 (Maven) consistent across all manifests ⏸️ untested no Only a manifest grep was run; no live product run was driven for this scenario, so the prior pass is not supported.
Unknown template variable raises on generated render path (verify payload tree passed) ✅ pass live bun probe of render() in server/typescript/packages/render/src/index.ts: 'Hello {{nmae}}' with verify tree threw ERR_VAR_NOT_ON_PAYLOAD (nmae)
Known template variable still renders on the same path ✅ pass live bun probe: 'Hello {{name}}' => 'Hello Ada' with and without verify tree
Unknown template variable without payload tree (inline render) ✅ pass live bun probe: 'Hello {{nmae}}' rendered 'Hello ' with no verify option
Python Mustache-helper unknown-variable path ⏸️ untested no Not exercised; it is in the base commit, not this diff. Would need a Python render run in a disposable uv env; not done within this step's scope.
  • scripts/ci-local.sh --only ts-fast --only ts-unit --strict-toolchains
  • Baseline: scripts/ci-local.sh --only ts-fast --only ts-unit --strict-toolchains (given, passed)
  • git diff --stat b34933713..aa21f0625 review (43 files, version/doc/lockfile only)
  • Version consistency: grep of package.json (14 at 1.3.0), server/java/pom.xml 8.3.0, pyproject 1.3.0, Directory.Build.props 1.3.0 (manifest read only, not live)
  • Live probe via bun on render() in server/typescript/packages/render/src/index.ts: known var renders; unknown var with no verify tree renders empty; unknown var with verify field tree throws ERR_VAR_NOT_ON_PAYLOAD
🔧 **Document** - 2 issues found → no changes applied ✅
  • ℹ️ README.md:163 - Version-bearing prose (README port table, server/java/README.md, AGENTS.md 'Where the versions are', fit-assessment sheet) still shows 1.2.0 / 8.2.0. Already declared by the user in review round 1 (review-1); not touched here. Restamp after publish or confirm plan.
  • ℹ️ docs/features/field-types.md:27 - docs/features/field-types.md:27 lists field.duration wire as 'string (ISO-8601)' for TypeScript. 1.3 makes native the default and ISO an opt-in via wire.durations; the TS native form was not verified from code, so the row may be correct as-is. Confirm the TS native duration wire form and reword the row if it differs.

🔧 No changes applied.
✅ Re-checked - no issues remain.

✅ **Lint** - passed

✅ No issues found.

✅ **Push** - passed

✅ No issues found.

… Central

Bump the 14 npm publish candidates, PyPI, NuGet and the Maven reactor in
lockstep, regenerate bun.lock and the site payload, restamp the llms
mirrors, and promote the CHANGELOG [Unreleased] section to [1.3.0] with an
upgrade summary. @sequenceStart is described as not moving an existing
counter in 1.3.0, with a forward-only move planned for a later release.
@dmealing
dmealing merged commit c75c30a into main Nov 12, 2026
9 checks passed
@dmealing
dmealing deleted the fm/mo-release-1-3-0 branch November 12, 2026 01:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant