Releasing (development alpha)

MMML versions are derived from git tags by versioningit (see [tool.versioningit] in pyproject.toml). A clean, tagged commit produces an exact version; anything after a tag gets a dev/local suffix.

Fast install (what end users get)

The alpha is distributed as a Python package, not a git clone:

pip install mmml            # or: uv pip install mmml

The wheel/sdist are ~11 MB (they exclude large repo data such as mmml/models/EF/data/, trajectories, and setup/charmm.tar.xz). pyCHARMM and a GPU are optional — see the README and Getting started.

Cut an alpha release

1. Make sure main is green and the working tree is clean.
2. Choose a PEP 440 pre-release version and tag it (annotated):

   git tag -a v0.1.0a1 -m "mmml 0.1.0a1 (alpha)"
   git push origin v0.1.0a1
   

   versioningit turns v0.1.0a1 into version 0.1.0a1.
3. Build and check the artifacts:

   uv build                       # writes dist/*.whl and dist/*.tar.gz
   uv run --with twine twine check dist/*
   

4. (Optional) Publish to PyPI / TestPyPI:

   uv run --with twine twine upload --repository testpypi dist/*
   

5. Create the GitHub Release from the tag and attach dist/* (and, if wanted, setup/charmm.tar.xz as a release asset rather than tracking it in git).

Keeping the git repo small

git clone is large because of binaries committed to history. To reduce it:

• Users (no rewrite needed): git clone --filter=blob:none <url> or git clone --depth 1 <url>.
• Maintainers (destructive, rewrites history, requires force-push and everyone re-clones): run scripts/slim_repo_history.sh --analyze then --rewrite. Do this only when active branches/PRs can be coordinated, and reclaim Git LFS storage afterwards (GitHub does not garbage-collect LFS objects automatically).

Do not commit new large/regenerable artifacts; .gitignore already covers node_modules/, *.dcd, *.traj, *.parquet, mmml/models/EF/data/, etc.