Skip to content

Release the Python client at 0.15.0 - #55

Merged
mgoldsborough merged 1 commit into
mainfrom
chore/python-0.5.0
Jul 28, 2026
Merged

Release the Python client at 0.15.0#55
mgoldsborough merged 1 commit into
mainfrom
chore/python-0.5.0

Conversation

@mgoldsborough

Copy link
Copy Markdown
Contributor

The drift, again

PyPI nimblebrain-synapse 0.4.0 ships the UI client built at @nimblebrain/synapse 0.14.0. Main carries 0.15.0.

This is the same gap #53 closed one release ago. It reopened on the very next npm release, which answers the open question from that PR: it is structural, not a one-off.

Why 0.5.0

The Python API is untouched, but the vendored client removes the warm tone and the warm / warmLight tokens. A component whose markup or CSS references them changes appearance, so this is not a drop-in. The changelog leads with the migration rather than the version arithmetic.

It also carries the 0.14.1 fix, where a partial document threw out of the handshake and left the app unable to connect.

pytest green — 18 passed. No source change beyond the version and changelog; the vendored asset is already current on main and gated by CI's freshness diff.

The gate — deliberately not in this diff

I worked through three shapes and none is obviously right, so this is a decision rather than something to slip into a release bump:

  1. Fail CI on main when __client_version__ differs from the newest nimblebrain-synapse-v* tag. Detects the drift directly — but goes red during every legitimate window between an npm release and its Python follow-up, which trains people to ignore it. Rejected.
  2. Fail the Python publish workflow if the vendored client is not npm latest. Safe, no false reds — but it only fires when someone already decided to release, so it prevents a bad release without ever surfacing a missing one. This is the drift we actually have.
  3. Fail a PR that changes the vendored IIFE without moving python/pyproject.toml. Same shape as the existing freshness diff, deterministic, no cross-tag lookups, and it puts the obligation on the change that causes it. The cost is that every SDK PR touching src/ then owes a Python version decision — Make the default theme a default: ship it in a cascade layer #50 and Do not take the connection down over a default layer #54 would both have tripped it.

I lean 3, because it forces the choice at the moment of change instead of letting it accumulate silently, and because "these two things must move together" is exactly what the existing freshness gate already asserts one level down. But it couples the two release trains, so it is your call.

Happy to add whichever you pick as a follow-up.

PyPI 0.4.0 ships the UI client built at `@nimblebrain/synapse` 0.14.0; main
carries 0.15.0. Same drift #53 fixed one release ago, recurred immediately,
which is the answer to whether it was a one-off.

0.5.0 rather than 0.4.1: the Python API is untouched, but the client removes
the `warm` tone and the `warm` / `warmLight` tokens, so a component
referencing them changes appearance. The changelog leads with that rather
than with the version arithmetic, since it is the only thing a consumer has
to act on.

No gate added here. The check that would catch this is worth having and is
not obvious enough to bundle into a release bump — see the PR body.
@mgoldsborough
mgoldsborough merged commit a65c56c into main Jul 28, 2026
7 checks passed
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