Add version for CLI and REST API. - #951

Every pull request against speedkick fails the "Run Python unit tests"
job on ubuntu and macos with

    FAILED .../common/api/test_version.py::test_get_version
    AssertionError: Invalid server version: 0.3.9.post2.dev14+g2c69bb83e

The annotated tag v0.3.9-post1 (2026-08-31, "Post-release build from
speedkick, after v0.3.9") sits on speedkick's ancestry and is the
nearest tag for every commit since, so setuptools-scm renders each
build as 0.3.9.post2.devN+g<sha>. The test's hand-written pattern had
no post-release segment. main is unaffected because the tag is not
reachable from it.

The test is deleted rather than patched. get_version() is a wrapper
around importlib.metadata.version for two distribution names; nothing
in it produces a version shape. The shape comes from setuptools-scm,
the repository's tags and the working tree, so the test could only
ever fail for environmental reasons, and that is its whole history:
the regex was widened in MemMachine#993 (dotted local segment), MemMachine#1038
(two-component tag) and would have been again here, while the function
under test has not changed since MemMachine#951 wrote it. It also rejected a
documented output: MemMachine#951 specifies client_version as "not available"
when memmachine-client is not installed, which is the case for a wheel
install of the server, whose package does not depend on the client.
The test passed only because the uv workspace installs every member.
test_version_string stays; it tests the model's own string form.

The check moves to the layer that owns it. The Test Server Package
workflow already builds the wheels and installs them; a new step runs
the installed memmachine-server --version and requires the reported
server version to equal the version in the wheel's filename. That ties
the binary to the artifact it shipped in without asserting anything
about the version's format.

Verified locally on this branch: the trimmed test file passes and is
clean under ruff check and ruff format --check; the new step, run
verbatim against wheels built from this tree and installed into a
fresh virtualenv, passes.

The windows unit-test jobs report success only because the step runs
under pwsh, which does not stop on the first command's non-zero exit
and returns the last command's status (the client suite). Their server
run fails this test plus two windows-only tests
(test_nebula_graph_vector_literals charmap decode, test_index_persistence
flush guard). That masking is left as is: forcing bash on the step
would turn windows red until those two are fixed.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_019zu1CSWVso2NA4bWPYmw8Z

…kick) (#1604)

Verify the version in the package workflow, not in a unit test

Every pull request against speedkick fails the "Run Python unit tests"
job on ubuntu and macos with

    FAILED .../common/api/test_version.py::test_get_version
    AssertionError: Invalid server version: 0.3.9.post2.dev14+g2c69bb83e

The annotated tag v0.3.9-post1 (2026-08-31, "Post-release build from
speedkick, after v0.3.9") sits on speedkick's ancestry and is the
nearest tag for every commit since, so setuptools-scm renders each
build as 0.3.9.post2.devN+g<sha>. The test's hand-written pattern had
no post-release segment. main is unaffected because the tag is not
reachable from it.

The test is deleted rather than patched. get_version() is a wrapper
around importlib.metadata.version for two distribution names; nothing
in it produces a version shape. The shape comes from setuptools-scm,
the repository's tags and the working tree, so the test could only
ever fail for environmental reasons, and that is its whole history:
the regex was widened in #993 (dotted local segment), #1038
(two-component tag) and would have been again here, while the function
under test has not changed since #951 wrote it. It also rejected a
documented output: #951 specifies client_version as "not available"
when memmachine-client is not installed, which is the case for a wheel
install of the server, whose package does not depend on the client.
The test passed only because the uv workspace installs every member.
test_version_string stays; it tests the model's own string form.

The check moves to the layer that owns it. The Test Server Package
workflow already builds the wheels and installs them; a new step runs
the installed memmachine-server --version and requires the reported
server version to equal the version in the wheel's filename. That ties
the binary to the artifact it shipped in without asserting anything
about the version's format.

Verified locally on this branch: the trimmed test file passes and is
clean under ruff check and ruff format --check; the new step, run
verbatim against wheels built from this tree and installed into a
fresh virtualenv, passes.

The windows unit-test jobs report success only because the step runs
under pwsh, which does not stop on the first command's non-zero exit
and returns the last command's status (the client suite). Their server
run fails this test plus two windows-only tests
(test_nebula_graph_vector_literals charmap decode, test_index_persistence
flush guard). That masking is left as is: forcing bash on the step
would turn windows red until those two are fixed.


Claude-Session: https://claude.ai/code/session_019zu1CSWVso2NA4bWPYmw8Z

Co-authored-by: Claude Fable 5.1 <[email protected]>

test_get_version asserts that get_version() returns a version matching a
hand-written pattern: release, optional .devN, optional local segment.
On speedkick that assertion fails on every pull request, because the
annotated tag v0.3.9-post1 (2026-08-31, "Post-release build from
speedkick, after v0.3.9") sits on that branch's ancestry and
setuptools-scm renders each build as 0.3.9.post2.devN+g<sha>, a shape
the pattern never allowed. main passes today only because that tag is
not yet reachable from it; it becomes reachable the moment speedkick
merges, and any post-release tag would do the same.

The test is deleted rather than patched. get_version() is a wrapper
around importlib.metadata.version for two distribution names; nothing
in it produces a version shape. The shape comes from setuptools-scm,
the repository's tags and the working tree, so the test could only
ever fail for environmental reasons, and that is its whole history:
the regex was widened in #993 (dotted local segment), #1038
(two-component tag) and would have been again here, while the function
under test has not changed since #951 wrote it. It also rejected a
documented output: #951 specifies client_version as "not available"
when memmachine-client is not installed, which is the case for a wheel
install of the server, whose package does not depend on the client.
The test passed only because the uv workspace installs every member.
test_version_string stays; it tests the model's own string form.

The check moves to the layer that owns it. The Test Server Package
workflow already builds the wheels and installs them; a new step runs
the installed memmachine-server --version and requires the reported
server version to equal the version in the wheel's filename. That ties
the binary to the artifact it shipped in without asserting anything
about the version's format.

Verified locally on this branch: the trimmed test file passes and is
clean under ruff check and ruff format --check; the new step, run
verbatim against wheels built from this tree and installed into a
fresh virtualenv, passes (and reports "client: not available", which
the deleted test would have rejected).

Unrelated but worth knowing: the pytest workflow's test step has no
shell key, so on windows it runs under pwsh, which does not stop on the
first command's non-zero exit and returns the last command's status
(the client suite). A server-suite failure on windows would not fail
the job. On main the windows server run passes today (1830 passed on
#1584's run), so nothing is hidden yet; on speedkick two windows-only
failures are. Forcing bash there is left for when those are fixed.

Same change as #1604 on speedkick, applied to main.

Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
Co-authored-by: Shu Wang <[email protected]>