|
Size: 1793
Comment:
|
Size: 3387
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| Line 9: | Line 8: |
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 user's hands more quickly, improve our planning process, and keep our development cycles from growing stagnant. |
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. |
| Line 13: | Line 11: |
| Starting with 6.1, Mercurial now follows a 4-month cycle with the following key dates: ||<tablewidth="818px" tableheight="121px">Freeze date | Major Release | Minor | Minor | Minor ||<tablewidth="818px" tableheight="121px">Feb 15 | Mar 1 | Apr 1 | May 1 | Jun 1 Jun 17 | Jul 1 | Aug 1 | Sep 1 | Oct 1 Oct 18 | Nov 1 | Dec 1 | Jan 1 | Feb 1 |
|
| Line 14: | Line 17: |
| Mercurial now follows a 4-month cycle with the following release dates: | |
| Line 16: | Line 18: |
| * Mar 1st * July 1st * Nov 1st |
|
| Line 20: | Line 19: |
| In each cycle, we have: | |
| Line 22: | Line 20: |
| * -2 weeks: feature freeze, default branch merged into stable * -2 weeks: focus moves to bug-stomping * -1 week: code free * 0: major release * 1 month: Zero or more bugfix releases |
[[https://www.google.com/calendar/embed?src=qr79bsktoma62568k4n7f466js@group.calendar.google.com|Google calendar]] [[https://www.google.com/calendar/feeds/qr79bsktoma62568k4n7f466js@group.calendar.google.com/public/basic|(rss feed)]] |
| Line 28: | Line 22: |
| All platforms should aim to have nightly autobuilders tracking the stable branch. | == 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: |
| Line 30: | Line 25: |
| '''Feature freeze:''' bug fixes, template fixes, doc fixes, and translation fixes only. Exceptions may be made for code that can be shown to have no regression or design impact (e.g. new convert back-ends). | * default branch is merged into stable * stable branch receives the {{{@}}} bookmark to be checked out in new clones * one -rc testing release is made, including binary packages * only patches suitable for the stable branch are accepted * packagers should start producing nightly builds if possible |
| Line 32: | Line 31: |
| '''Code freeze:''' regression bug fixes, doc fixes and translation fixes only. Exceptions will be made on a case-by-case bases for noteworthy bugs. Doc fixes are discouraged at the end of this period. | 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) == 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: * bug fixes * error message improvements * doc fixes * template fixes * improved translations Things that don't belong on the stable branch: * code cleanups * spelling corrections in comments, etc. * minor performance fixes * test improvements that don't accompany a fix * all work related to new features * everything else 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. |
| Line 35: | Line 58: |
Minor releases will be made by tagging the current state of the stable branch, which is continually kept in a production-ready state. |
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. |
Time-based Release Plan
How we manage releases.
Contents
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 6.1, Mercurial now follows a 4-month cycle with the following key dates: ||<tablewidth="818px" tableheight="121px">Freeze date | Major Release | Minor | Minor | Minor ||<tablewidth="818px" tableheight="121px">Feb 15 | Mar 1 | Apr 1 | May 1 | Jun 1 Jun 17 | Jul 1 | Aug 1 | Sep 1 | Oct 1 Oct 18 | Nov 1 | Dec 1 | Jan 1 | Feb 1
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:
- default branch is merged into stable
stable branch receives the @ bookmark to be checked out in new clones
- one -rc testing release is made, including binary packages
- only patches suitable for the stable branch are accepted
- packagers should start producing nightly builds if possible
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.
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
![/!\](/moin-static/modernized/img/alert.png "/!\"){kind=small}
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:
- bug fixes
- error message improvements
- doc fixes
- template fixes
- improved translations
Things that don't belong on the stable branch:
- code cleanups
- spelling corrections in comments, etc.
- minor performance fixes
- test improvements that don't accompany a fix
- all work related to new features
- everything else
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.