1.0.0-rc.5 — first RC on all four registries

The first release candidate cut to all four registries. rc.1–rc.4 were npm-only, so until now no adopter could exercise the JVM, Python or C# side of 1.0.

Registry	Version	Artifacts
npm	1.0.0-rc.5	14 @metaobjectsdev/* packages, dist-tag next
PyPI	1.0.0rc5	metaobjects
NuGet	1.0.0-rc.5	MetaObjects, .Render, .Codegen, .Cli
Maven Central	8.0.0-rc.5	14 com.metaobjects:* modules

metamodelVersion 1.0. The JVM line moves to major 8 per ADR-0035's decoupled cut — npm/PyPI/NuGet →1.0.0, Java/Kotlin →8.0.0, both forward, tied by the shared metamodel version rather than by a shared coordinate.

Installing

npm i @metaobjectsdev/cli@next          # or: pnpm add @metaobjectsdev/cli@next
pip install metaobjects==1.0.0rc5
dotnet tool install --global MetaObjects.Cli --version 1.0.0-rc.5

<dependency>
  <groupId>com.metaobjects</groupId>
  <artifactId>metaobjects-metadata</artifactId>
  <version>8.0.0-rc.5</version>
</dependency>

Breaking since 1.0.0-rc.4

Three changes an estate pinned to rc.4 has not seen:

• attr("isArray") now throws. isArray is a reserved structural keyword, not an attribute; reading it through the attribute accessor was returning nothing and silently dropping array-ness.
• useEntityFetcher rename in the React/TanStack client seam.
• verify --docs verdict change — it now honours .gitignore, evaluated over the fresh page set by name, so the denominator is identical on a dev box and on a CI runner.

What this is for

This is the release candidate the 1.0 readiness gate G3d runs against: an adopter estate must run it with the drift gate ENFORCED before 1.0 is promoted. Report anything it breaks on the issue tracker.

Verification

node scripts/release-verify.mjs 1.0.0-rc.5 — all four registries green. Both an npm and a pnpm external install run init, gen, docs, upgrade and verify; a cold pnpm project typechecks its generated code at exit 0, then migrates and verifies a sqlite database clean.

Known issue in this tag

The tag's own conformance run found a Java test-only defect and it is fixed on main after the tag: ConstraintSystemTest.testRequiredAttributeConstraint asserted on the text of a NullPointerException the JVM raises, and HotSpot's fast-throw optimisation stops producing that text once the path is hot — which a 1554-test full-reactor run reaches and a single class does not. Green on every developer box, red in the full-reactor job. No published artifact is affected: the file ships in no package. Fixed in 1c24b8f9d, along with pinning surefire, which had been resolving to three different versions (3.2.5 locally, 3.5.4 on the runner, 3.5.2 pinned) over the same test set.