An overview of the Mercurial development process.
1. Code review
Anyone may contribute to Mercurial. All contributions are sent as patches to the mercurial-devel mailing list and reviewed on-list. It's not necessary to subscribe to the list to send patches; reviewers will CC the submitter when replying. You can also submit patches by pushing to the "pushgate" repository at https://selenic.com/repo/hg-push. See ContributingChanges for contribution guidelines and how to get started.
Before submitting a patch, please go thru the checklist on ContributingChanges.
Anyone may review patches as well. It's often helpful to have input from community members on new contributions. See ReviewProcess for more on reviewing other people's changes.
If you see a patch on mercurial-devel that interests you, feel free to comment on it!
2. Accepting patches
3. Development branches
Mercurial is developed on two branches in the main repository:
default — for all new development, refactoring, testing, performance improvements, etc.
stable — for bug fixes, documentation/translation/error message improvements
There is only one officially supported release of Mercurial at a time, represented by the stable branch. Minor releases are cut from stable at the beginning of every month.
4. Code freeze
Major feature releases of Mercurial happen every three months. Approximately two weeks before a major release, Mercurial goes into code freeze. No new feature patches are accepted during code freeze; during this time the core contributors on fixing bugs, improving documentation, and updating translations. See TimeBasedReleasePlan for more details.
Releases are made by tagging and GPG-signing the stable branch in the main repository. A source archive (.tar.gz) is published on the downloads page. Binary packages are also available (but may lag behind the source release for a time).
If you are a package maintainer, ensure that you're subscribed to the mercurial-packaging list.