Time-based Release Plan

How we manage releases.

1. Theory

Up until version 1.1, Mercurial took a "when it's ready" approach to releases. Starting with version 1.2, we've switched to a consistent calendar-based release schedule. This helps us get bug fixes and new features into our users' hands more quickly, improve our planning process, and keep our development cycles from growing stagnant.

2. Major releases

Starting with 2.0, Mercurial now follows a 3-month cycle with the following key dates:

Freeze date

Major Release

Minor

Minor

Jan 17

Feb 1

Mar 1

Apr 1

Apr 16

May 1

Jun 1

Jul 1

Jul 18

Aug 1

Sep 1

Oct 1

Oct 18

Nov 1

Dec 1

Jan 1

Google calendar (rss feed)

3. Code Freeze

Each release cycle ends with a code freeze that starts approximately two weeks before the release date. When the code freeze begins, the following things happen:

The point of the freeze is to get everyone to focus on testing and bug fixes for the upcoming release, so please don't distract from that by sending RFC patches or starting feature discussions.

{i} Please be aware that translators need time to synchronize translations before releases so avoid unnecessary string changes in the last few days of the freeze

/!\ All developers should be sure to check out the stable branch after the freeze is declared (no commits on default, also don't merge stable into default)

4. Rules for code freeze and stable branch commits

Because the code freeze is on the stable branch, the rules for each are the same. The following are allowed:

Things that don't belong on the stable branch:

The guiding rule for stable is to reduce user-visible defects while minimizing risk and churn. If a change has no user impact, it's not appropriate for stable, even if it has no apparent risk.

5. Minor releases

Minor releases will be made by tagging the current state of the stable branch, which is continually kept in a production-ready state, except for possible issues during the early days of the freeze.

Releases will be made in a timely manner for significant behavior regressions, data integrity issues, or security issues.

Barring such issues, minor releases will be made on or about the first of every month that doesn't coincide with a major release.


CategoryDeveloper CategoryProcess

TimeBasedReleasePlan (last edited 2017-10-13 19:13:58 by KevinBullock)