[tae898]

Closes #309

26.12.1.dev1 is an unpublished tag: its release failed before any upload (native: the pin check after the build, JVM: one flaky docs test). 26.12.1.dev0 stays on PyPI as it is: it has no native win_amd64 wheel (the Windows parity jobs failed on a test that #308 fixed) and its native wheel printed ENGINE_SNAPSHOT None (also fixed in #308). 26.12.1.dev2 is the next release.

Native, root cause: native/pom.xml took -Darcadedb.version=26.12.1-SNAPSHOT, which Maven resolves to the newest Sonatype build at build time, and engine and server list their sibling modules at the floating version too.

• A .devN release now passes the pinned timestamped snapshot (26.12.1-20261106.183100-26) to Maven (maven-engine output of the plan step, used as ARCADEDB_ENGINE_VERSION); engine stays 26.12.1-SNAPSHOT for the checks, and the wheel still records ENGINE_VERSION, ENGINE_SNAPSHOT and ENGINE_IMAGE_DIGEST. A manual run can name one with the new maven-engine input (only for a SNAPSHOT engine of the same base).
• native/pom.xml manages the other com.arcadedb modules (console, graphql, grpc, integration, mcp) at ${arcadedb.version}, so a transitive one cannot float.
• dev_engine_pin.py check compares the pinned timestamped jars on Sonatype, not the newest ones, so it no longer fails when upstream deploys. I checked with HEAD that the jar and pom of all nine modules exist at the pinned timestamp; the check passes now although build 28 is the newest.
• After the build, the wheel step reads build.log and fails when arcadedb-engine-<snapshot>.jar is not on the classpath or any arcadedb-* jar there is another version.
• Not pinned: the parent pom (arcadedb-parent:26.12.1-SNAPSHOT) that the engine pom names still resolves to the newest one, so a third-party version that only the parent manages can move; native/pom.xml already manages the versions the wheel ships.

JVM flake: the TERMS count of the other facet in the unavailable-hierarchy example was 3 once and 6 otherwise. I could not reproduce it (0 of 350 fresh databases, native and JVM dev0 wheels: always source scan, count 6), so I cannot say if it is a lagging index or an engine race. The page block and test_unavailable_facet_is_surfaced no longer print or assert that count, they check the facet's type and that its source is index or scan, and the page says a count is read with its source and meta. The open engine question goes to the maintainers separately.

Tests: tests/test_dev_engine_pin.py runs the real plan step for the maven-engine cases (the timestamp is refused for a final release, for a release engine and for another base).

🤖 Generated with Claude Code