Differences between revisions 9 and 10
Revision 9 as of 2010-10-15 09:34:20
Size: 1610
Editor: abuehl
Comment: cat and style fixes
Revision 10 as of 2010-10-15 10:15:27
Size: 1718
Editor: mpm
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Time-based release plan =
Up until version 1.1, Mercurial took 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.
#pragma section-numbers 2
= Time-based Release Plan =

How we manage releases.

<<TableOfContents>>

== Theory ==

Up until version 1.1, Mercurial took a "when it's ready" approach to releases. Starting with version 1.2, we've switch 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.
Line 5: Line 13:
Line 26: Line 35:
Line 33: Line 43:
CategoryDeveloper CategoryDeveloper CategoryProcess

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 switch 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
  • -2 weeks: bug-stomping sprint
  • -1 week: code freeze
  • -1 week: prerelease testing window with binaries available
  • -1 week: stable tracks tip until release
  • 0: major release
  • 1 month: Zero or more bugfix releases

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 (eg 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.

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.


CategoryDeveloper CategoryProcess

TimeBasedReleasePlan (last edited 2022-01-06 08:36:10 by RaphaelGomes)