[Feat]: Keep all components aligned on the same version at any commit #830

Activity

1. Kevin-K-W

   added the

   Feature

   issue type on Dec 18, 2025
2. Kevin-K-W

   assigned

   sscargal

   on Dec 18, 2025
3. sscargal commented on Dec 18, 2025

   

   sscargal

   on Dec 18, 2025

   Contributor

   More actions

   Thank you for raising this important issue. You’re absolutely right: having a hard-coded version (e.g., 0.1.0 in pyproject.toml) leads to confusion, especially when building artifacts directly from the main branch, as those artifacts may not match an actual released version. Although your current CI setup uses sed to update the version during builds, this doesn’t help when building locally or guarantee that static version files in the repo stay in sync.

   Recommended Solution: SCM-Based Versioning

   The industry best practice for synchronizing versions across all builds (CI or local, tagged or main) is to derive the version directly from your source control tags and commits using an SCM-based versioning tool.

   What to Change – uv Build System with SCM Versioning

   1. Use scm-version in pyproject.toml

   uv has built-in support for SCM versioning via the scm-version field.
   Replace the hard-coded version field in your Python packages’ pyproject.toml with:

   [project]
   name = "memmachine-client"
   scm-version = true

   • Remove any version = "..." field in [project].
   • This tells uv to derive the version from the nearest Git tag at build/install time, just like setuptools_scm.
   • This will yield versions like 0.1.0 (on a tag) or 0.1.0.dev34+gabcdef1 (if 34 commits after the tag).

   Documentation: https://docs.astral.sh/uv/guides/versioning/#scm-version

   ---

   2. Remove All Static __version__ Strings

   Where Python code expects a version string, use dynamic lookup based on the built package:

   try:
       from importlib.metadata import version
   except ImportError:
       from importlib_metadata import version  # For Python <3.8
   
   __version__ = version("memmachine-client")

   • Remove all manual updates to __version__ in source files.

   ---

   3. Remove All sed/patching Steps From Workflows

   • In .github/workflows/build-python.yml, remove the “Patch version in pyproject.toml” step and any sed-based version injections.
   • Remove any patch-version inputs in workflows such as pypi-publish.yml and installation-test.yml, as SCM versioning makes these unnecessary.
   • From now on, no workflow should ever modify the version field in pyproject.toml—it should always be derived from git.
   • Identify all other GitHub Workflows and modify them to use this new version approach.

   ---

   4. Build Commands Stay the Same

   • Running uv build --project packages/client will now always yield a wheel with the correct SCM-derived version, both locally and in CI.
   • No changes are needed to your uv build commands in the workflow steps.

   5. Test

   • Verify all current build methods work using the new versioning approach
   • Verify all Workflows work correctly using this new versioning approach

   👍React with 👍2Reacted by tianAndrew and Jing
4. Kevin-K-W

   assigned

   tianAndrew

   on Dec 22, 2025
5. jgong commented on Jan 7, 2026

   

   jgong

   on Jan 7, 2026

   Contributor

   More actions

   Hi @Kevin-K-W @sscargal, thanks for opening this and for the detailed versioning solution! One quick question: once the memmachine-server is up and running, is there a way to retrieve this SCM-derived version? I think having that visibility would be really helpful for us to quickly identify exactly which version is active.
6. sscargal commented on Jan 7, 2026

   

   sscargal

   on Jan 7, 2026

   Last edited by sscargal

   Contributor

   More actions

   We should definitely do that. I'll create a new feature request as there are a few things we can do to improve identification using versioning.

   👍React with 👍1Reacted by Jing
7. sscargal

   closed this as completedin #866on Jan 9, 2026