|
Size: 821
Comment:
|
Size: 2029
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| == Time-Base Release Plan == | #pragma section-numbers 2 = Time-based Release Plan = How we manage releases. |
| Line 3: | Line 5: |
| Mercurial has so far taken a "when it's ready" approach to releases. As we mature, it probably makes sense to switch to a consistent release schedule. This will help us get bug fixes and new features into our user's hands more quickly, improve our planning process, and hopefully keep our development cycles from growing stagnant. | <<TableOfContents>> |
| Line 5: | Line 7: |
| Post-1.1, I propose a 4-month cycle with the following release dates: | == 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. |
| Line 7: | Line 10: |
| * Mar 1st - [http://www.selenic.com/pipermail/mercurial-devel/2009-January/010031.html Feature freeze Feb 14th] * July 1st |
== Major releases == Starting with 2.0, Mercurial now follows a 3-month cycle with the following release dates: * Feb 1st * May 1st * Aug 1st |
| Line 11: | Line 18: |
| In each cycle, we have: | == Code Freeze == Each release cycle ends with a code freeze that starts '''approximately two weeks before the release date'''. When [[mpm]] begins the code freeze, the following things happen: |
| Line 13: | Line 21: |
| * -2 weeks: feature freeze * -2 weeks: bug-stomping sprint * -1 week: code freeze * -1 week: prerelease testing window with binaries available * 0: major release * 1 month: Zero or more bugfix releases |
* default branch is merged into stable * 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 following changes are accepted on the stable branch (at all times): * bug fixes * error message improvements * doc fixes * template fixes * improved translations {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) == 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. 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 |
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 2.0, Mercurial now follows a 3-month cycle with the following release dates:
- Feb 1st
- May 1st
- Aug 1st
- Nov 1st
3. Code Freeze
Each release cycle ends with a code freeze that starts approximately two weeks before the release date. When mpm begins the code freeze, the following things happen:
- default branch is merged into stable
- 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 following changes are accepted on the stable branch (at all times):
- bug fixes
- error message improvements
- doc fixes
- template fixes
- improved translations
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. 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.
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.