Edgewall Software

Version 45 (modified by Christian Boos, 9 years ago) ( diff )

explain how we use our milestones

Trac's Road Ahead

See the Roadmap page for the official schedule.

You'll find there the currently opened Milestones, but you can also use the filter panel at the upper right corner of the page to select "closed milestones" to get an overview of the whole project's life.

Milestone Categories

A short summary of what you'll find there:

  • Milestones corresponding to major releases:
    • 0.12 - the upcoming major release (May 2010)
    • 0.13 - the next major release (December 2010)
    • next-major-0.1X - pool of tickets relevant for one of the next major feature releases
  • Milestones corresponding to minor releases:
    • 0.12.3 - the next maintenance release for 0.12.x
    • next-minor-0.12.x - pool of tickets relevant for one of the next minor maintenance releases
  • Milestones which don't correspond to a Trac release:

High-level Workflow

Detailed guidelines can be found on each milestone, but here's how things generally work:

  • minor releases contain generally bug fixes, no (or only minor) new features; the greater the minor version number, the closer we stick to this rule
  • major releases contain the great new features, the major refactorings to address design flaws, and so on

The fate of an individual ticket generally goes along one of the following paths:

  • new tickets have no milestone set, the Trac developers use that as indicator that the ticket has not been triaged yet (among other reasons, this is why you shouldn't set the milestone yourself, otherwise you take the risk that the ticket will not be noticed for a while)
  • if we're in the early period of the stabilization of a major release (0.1X.1, 0.1X.2) and the ticket reports a valid defect, the ticket will likely go in next-minor-0.1X pool of tickets
    • from there, a developer eventually picks it and moves it to the actual 0.1X.Y minor release; factors that influence this selection are the impact of the issue (severity), but also how well the defect is explained and documented, if there's a patch provided or not, …
  • if it's a proposed feature and we like it, or a minor defect we'll take care to fix, the ticket goes in the next-major-0.1X pool
    • from there, a developer eventually picks it and moves it to the actual 0.1X major release
  • if we don't really like the proposed feature, or think the reported defect is not worth fixing, but we're not strongly opposed to it either, the ticket becomes unscheduled; it may eventually move from there to a more concrete milestone depending on the involvement of contributors
  • otherwise the ticket is rejected

You can usually influence how a ticket moves from one category to the other by providing the requested feedback, clarifications about the issue or the code you contributed (about code contributions, see PatchWelcome for details).

Note that the planned release dates are not bounding, they should only be taken as an estimation. We're also using the dates as a way to order the milestones.

See also SeaChange for a general discussion about what users (and developers) would like to see happening in Trac.

Note: See TracWiki for help on using the wiki.