|
Size: 719
Comment:
|
Size: 1787
Comment: I suppose it should be "code freeze" instead of "code free"
|
| 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 user's hands more quickly, improve our planning process, and keep our development cycles from growing stagnant. == Major releases == Mercurial now follows a 4-month cycle with the following release dates: |
| Line 13: | Line 19: |
| * -2 weeks: feature freeze * -2 weeks: bug-stomping sprint |
* -2 weeks: feature freeze, default branch merged into stable * -2 weeks: focus moves to bug-stomping |
| Line 16: | Line 22: |
| * -1 week: prerelease testing window with binaries available | |
| Line 19: | Line 24: |
All platforms should aim to have nightly autobuilders tracking the stable branch. '''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). '''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. == 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 user's hands more quickly, improve our planning process, and keep our development cycles from growing stagnant.
2. Major releases
Mercurial now follows a 4-month cycle with the following release dates:
- Mar 1st
- July 1st
- Nov 1st
In each cycle, we have:
- -2 weeks: feature freeze, default branch merged into stable
- -2 weeks: focus moves to bug-stomping
- -1 week: code freeze
- 0: major release
- 1 month: Zero or more bugfix releases
All platforms should aim to have nightly autobuilders tracking the stable branch.
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).
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.
3. 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.