The build had broken again. No one knew why. The commit was clean, the tests were green, but somewhere between push and deploy, chaos slipped in. This is where Mercurial stable numbers earn their name.
Mercurial stable numbers are more than version tags. They are reproducible build identifiers tied to known-good changesets. A stable number points to a fixed commit in the repository, verified and locked. It is a promise: pull this number, get the same code every time. No drift. No surprises.
In Mercurial, every changeset has a unique hash. Stable numbers make this concrete by mapping human-readable identifiers to those hashes. This allows automated systems to pin exact states across environments. Whether you deploy to staging, production, or run CI pipelines, a stable number guarantees you’re using the intended snapshot.
Without stable numbers, you risk deployments from moving targets—branches that shift as new commits arrive. This leads to bugs that can’t be reproduced, inconsistent test results, and mismatched builds between developers and servers. Stable numbers cut out this uncertainty. They give teams a clear anchor for debugging, auditing, and rollback.