progovoy/vmn

<h1 align="center"vmn</h1

<p align="center"<stronggit checkout for releases that span many repos.</strong</p

<p align="center" Record a release once. Put the app and every repo it depends on back to exactly that state with one command.<br No server. No database. Any language. </p

<p align="center" <a href="https://pypi.org/project/vmn/"<img src="https://img.shields.io/pypi/v/vmn?logo=pypi&logoColor=white&label=PyPI" alt="PyPI version"</a <a href="https://pypi.org/project/vmn/"<img src="https://img.shields.io/pypi/pyversions/vmn?logo=python&logoColor=white" alt="Supported Python versions"</a <a href="https://github.com/progovoy/vmn/blob/master/LICENSE.txt"<img src="https://img.shields.io/github/license/progovoy/vmn" alt="MIT license"</a </p

<p align="center"<img src="demo/vmn-goto.gif" alt="vmn stamp, then vmn goto restoring the app and both dependency repos" width="820"</p

Production broke after last Tuesday's 2.1.0 deploy. Your product is four repos. Which commit of each one actually shipped?

Without vmn, that is an afternoon of CI logs and container tags. With vmn:

vmn goto -v 2.1.0 my_platform   # every repo back at the commit that shipped

Try it in any Git repository:

pipx install vmn

vmn stamp -r patch my_app       # 0.0.1
vmn goto -v 0.0.1 my_app        # restore the app and every configured dependency

vmn stores release metadata as readable YAML in annotated Git tags. Each tag records the application revision, dependency revisions, previous version, and release context. There is no vmn server and no external metadata database.

Developed continuously since 2019, vmn is used in daily production workflows by teams at large companies managing multi-repository products. vmn versions its own releases. The repository contains more than 400 tests, including Docker-backed multi-repository, recovery, and compatibility scenarios.

If vmn saves you an afternoon, a ⭐ helps other teams find it.

Quick start · Why vmn · Multi-repository recovery · Operations · Commands · Documentation

Why vmn

| Requirement | What vmn provides | | --- | --- | | Recover a recorded multi-repository source state | vmn goto restores the application and its configured dependencies to their recorded Git revisions. | | Keep release data inspectable | Annotated tags contain readable YAML and use the namespaced form <app<version. | | Version mixed technology stacks | vmn operates on Git repositories, not a language-specific package manager or build system. | | Release services independently | Root apps group independently versioned services under a monotonic composition version. | | Work without a hosted control plane | A standard Git remote is enough; internal and air-gapped Git servers are supported. | | Adopt without replacing build tooling | Version backends update npm, Cargo, Poetry, PEP 621, Jinja2, or regex-selected files. |

vmn treats a version as a handle to recorded source state, not only as a string. The same model supports releases, working snapshots, and measured runs:

| State | Command | Captures | | --- | --- | --- | | Release | vmn stamp → vmn goto | Committed application and dependency revisions | | Working | vmn snapshot | Release state plus local commits, tracked changes, and untracked files | | Measured | vmn exp | Working state plus metrics, parameters, artifacts, and run history |