Repository navigation
[Feat]: Improve version identification across all MemMachine artefacts and deployments #915
Description
Activity
Current State
- Docker tags: Are versioned (good industry practice) and multi-arch (good!).
- Floating tags (
latest-*): Present for convenience, but less traceable. - Versioned tags (
vX.Y.Z-*): Available; users can pull specific versions.
See available images and tags on Docker Hub
Gaps and Possible Enhancements
-
Application/log-level version visibility:
- The main gap is that end-users (or support/dev team) who run MemMachine containers may not see the version string of the running instance easily in logs, CLI, or API.
- If a user pulls
memmachine/memmachine:latest-gpuand runs it, the logs should showMemMachine version: v0.2.2-gpu (built from commit 26161e45fbce)or similar.
-
CLI Version Reporting:
- Running
memmachine --versionin a container (or installed software) should return the version string derived from the build/tag/git SHA. - This helps users know exactly what they're running, rather than guess based on the tag.
- Running
-
Fallback to Commit SHA:
- If the build is not on a tagged release, display the commit SHA transparently in all reporting locations (logs/CLI/API).
- This matches the alternatives described in [Feat]: Improve version identification across all MemMachine artefacts and deployments #915.
-
Version API/SDK Propagation:
- All MemMachine SDK and plugin components should expose the version string through an API property, function, or endpoint.
-
Consistent Startup Messaging:
- Emulate Neo4j/Postgres: on startup, clearly print the version and relevant tags/SHA in a consistent format.
Recommendations
Here’s how we might fulfill this issue based on what’s already implemented, and next steps:
- Derive version information at build time. Use the mechanism referenced in issue #830 to consistently set a version string for every build artifact.
- Inject version string into each artefact/environment:
- For Docker: Use build args/environment variables to make the version/tag/SHA available, print it on startup.
- For SDK/CLI: Add a
--versionoption, print out the version + commit SHA. - For plugins: Add a version property.
- Document: Make sure the documentation covers where users can find the version information.
- Backfill old releases: Optionally, ensure earlier releases also get versioned tags for consistency.
Example Implementation (Pseudo-Python for Startup Log/CLI):
# main.py VERSION = os.environ.get('MEMMACHINE_VERSION', 'dev') COMMIT_SHA = os.environ.get('MEMMACHINE_COMMIT', '') def print_startup_message(): print(f"MemMachine version: {VERSION} ({COMMIT_SHA})") def main(): print_startup_message() # Continue with app setup... if __name__ == "__main__": main()
And in Dockerfile:
ARG VERSION ARG COMMIT_SHA ENV MEMMACHINE_VERSION=$VERSION ENV MEMMACHINE_COMMIT=$COMMIT_SHA
Is your feature request related to a problem?
Currently, version identification for MemMachine artefacts and running instances is inconsistent, making it challenging to determine which version a component or container reflects. Users building from
mainor running containers can't easily tell which GitHub release/tag or commit their instance was built from. This leads to confusion in compatibility, troubleshooting, and upgradeability—especially for Docker images, where tags likelatest-cpuandlatest-gpudo not provide version granularity. Other mature projects such as Neo4j and Postgres always include explicit versions in Docker image tags and log startup output, creating much better traceability.Describe the solution you'd like
Implement a system so every MemMachine component (including server, Python SDK, plugins, etc.) derives and exposes a consistent version string from the latest GitHub tag or release, or from a helper introduced for issue #830. The version string should be visible anywhere a user might interact:
memmachine/memmachine:vX.Y.Z-cpu,memmachine/memmachine:vX.Y.Z-gpu, as well as updatinglatest-cpuandlatest-gpu(as floating tags). Use the commit SHA as a fallback when not on a tagged commit.memmachine-compose.sh), log the version (with commit hash if not exactly on a release).memmachine --versioncommand to report the running version regardless of install method.This mirrors industry best practices and will vastly improve visibility and support for users and the dev team.
Describe alternatives you've considered
latest,latest-cpu,latest-gpu), but always add immutable version tags for every build.devandrcin image tags and version printout.Additional context
Examples from other projects:
docker compose up, logs for MemMachine should show version info similar to how Neo4j or Postgres do on startup.latest.Issue #830 describes a starting point for deriving versions from tags.