Skip to main content
The rest of this site documents the current release, 0.2.3. This page is the version history: what each release improved, and the handful of things that need a change on your side when you upgrade. All ecosystems share one version number. See Installation for the pinned commands.

0.2.3

What’s now better supported

Numbers survive the round trip on the JVM. A CEL result is converted against the method’s declared kind, so double ← 77 arrives as 77.0 and int ← 77.0 as 77. A value that does not fit the declared kind now fails loudly instead of being narrowed silently: short ← 70000 raises 70000 is out of range for the declared kind Int16, and int ← 4294967296 raises rather than arriving as 0. Container-typed expressions validate cleanly. A typed list or map annotation no longer draws a spurious type-mismatch warning while the override applies. List<String> and Map<String,Integer> on the JVM, list[str] in Python, and list, map and top-level container overrides in Go all validate with no issues and still apply. Context-function diagnostics tell the truth. ctx.* calls used to be reported as unknown functions whether or not they existed. A declared context function now validates clean on the JVM, Kotlin and Python, and only a genuinely undeclared one is flagged — so the warning channel is worth reading again. Python handles more of the language. Keyword and mixed positional/keyword calls reach the VPoint body and take their stage. Modules using from __future__ import annotations resolve their forward references instead of silently never applying. Sets and frozensets keep their element type, Pydantic models reconstruct from a CEL literal the same way dataclasses do, and Optional[T] returns validate against their inner type. A lazily-registered VPoint returning a list accepts a CEL list result. Node fills struct fields from CEL list literals. Resp { productIds: ["A", "B"] } constructs the struct as written. List wrapper types are also named after the element they carry, so two VPoints whose signatures use arrays of different element types no longer share one catalog entry. The JVM speaks the same container grammar as every other runtime. Container lookup names were the JVM’s own snake_case spelling and are now the shared form — see the migration note below.
Some of these are coordinator-side. The container-kind and context-function diagnostics improve as soon as you run a 0.2.3 coordinator, even against an older SDK; the JVM numeric conversions need the 0.2.3 SDK. If you pin the two separately, upgrade the coordinator first.

Migration notes

1. The coordinator endpoint variable

The one that fails silently. The canonical name is VARIANZ_COORDINATOR_ENDPOINT. Go, the JVM and C++ read only that name. A JVM CI suite still exporting VARIANZ_ENDPOINT falls back to http://127.0.0.1:50051, insert() returns an id, awaitSyncOrFail() passes, and every stage quietly does nothing — a green run that tested nothing.
Node and Python still accept the older spellings — VARIANZ_COORDINATOR_ADDR, VARIANZ_ENDPOINT, VARIANZ_TEST_ENDPOINT — and warn once per process. Those shims are scheduled for removal before 1.0, so migrate anyway. Full precedence rules, including the fact that the variable outranks an endpoint passed in code, are in Configuration.

2. “Registry” is now “coordinator”

Older than 0.2.3 — the rename landed in 0.2.1 — but it is still the most common reason a copied snippet does not work, so it belongs here. The service is the coordinator throughout: “Registry” in these docs now only ever means a package registry — PyPI, npm, Maven Central, pkgs.varianz.io.

3. JVM container lookup names

The JVM was the only runtime spelling container types in snake_case. Those names are now the shared grammar, so a CEL expression or a hand-written schema reference that names one needs updating: Most expressions never name a container type and need no change. Diagnostics now render containers in CEL’s own vocabulary — list<string>, map<string, int> — whichever runtime is serving the VPoint.

4. Cross-type CEL results are coerced, not rejected

A CEL result whose type differs from the declared return type used to fail the call. It is now converted: on a VPoint declared to return a string, a CEL 42.9 arrives as "42.9" and true as "true", with no error. The same applies to a struct field. This is a deliberate change of direction, and it is an open policy question rather than a settled contract — it could change again. Documented here so you are not left to discover it under a retry loop: if a test relied on a mistyped override failing, it will now pass with a coerced value. Assert on the type as well as the value where the type matters.

0.2.2

The coordinator began reporting warning-severity CEL diagnostics instead of dropping them, which is what makes the validation channel worth reading at all. Node gained conversion of CEL stage results against the declared return kind, and construction of fieldless structs. Python got an idempotent register(), a working local-only mode, honest struct returns, and nested proto message resolution. Coordinator image archives began publishing to pkgs.varianz.io, which is how you obtain the image today. The endpoint variable at this release was still VARIANZ_COORDINATOR_ADDR.

0.2.1

The first release this documentation describes, covering the five application SDKs — Python, TypeScript/JavaScript, Go, Java and Kotlin — with the pytest, Vitest, Playwright, JUnit 5/Kotest and go test integrations. The registry → coordinator rename landed here, renaming the image, the COORDINATOR_* server settings and the SDK entry points.