[Feat]: Improve version identification across all MemMachine artefacts and deployments #915

Activity

1. sscargal

   self-assigned this

   on Jan 7, 2026
2. sscargal

   added the

   Feature

   issue type on Jan 7, 2026
3. sscargal commented on Jan 7, 2026

   

   sscargal

   on Jan 7, 2026

   ContributorAuthor

   More actions

   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

   1. 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-gpu and runs it, the logs should show MemMachine version: v0.2.2-gpu (built from commit 26161e45fbce) or similar.

   2. CLI Version Reporting:

      • Running memmachine --version in 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.

   3. 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.

   4. Version API/SDK Propagation:

      • All MemMachine SDK and plugin components should expose the version string through an API property, function, or endpoint.

   5. 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 --version option, 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
4. sscargal commented on Jan 16, 2026

   

   sscargal

   on Jan 16, 2026

   ContributorAuthor

   More actions

   Fixed by #951
5. sscargal

   closed this as completedon Jan 16, 2026