Edgewall Software

Changes between Version 46 and Version 47 of RoadMap


Ignore:
Timestamp:
Jun 23, 2012, 3:56:13 PM (9 years ago)
Author:
Christian Boos
Comment:

major update detailing the organization of milestones post-1.0

Legend:

Unmodified
Added
Removed
Modified
  • RoadMap

    v46 v47  
    11= Trac's Road Ahead
    22
    3 See the [/roadmap Roadmap] page for the official schedule.
     3This page gives insight about how past, current and future releases of Trac are organized.
    44
     5See the [/roadmap] itself for the list of milestones along with their description.
    56You'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.
    67
    78== Milestone Categories
    8 A short summary of what you'll find there:
    9  - Milestones corresponding to **major** releases:
    10    - [milestone:0.12] - the upcoming major release (May 2010)
    11    - [milestone:0.13] - the next major release (December 201**1**)
    12    - [milestone:next-major-0.1X] - pool of tickets relevant for one of the next major feature releases
    13  - Milestones corresponding to **minor** releases:
    14    - [milestone:0.12.3] - the next maintenance release for 0.12.x
    15    - [milestone:next-minor-0.12.x] - pool of tickets relevant for one of the next minor maintenance releases
    16  - Milestones which don't correspond to a Trac release:
    17    - //[query:milestone=&status!=closed (no milestone)]// - tickets that have to be triaged to other milestones
     9
     10Until 1.0, Trac releases followed a linear sequence of //major feature// releases, with //minor maintenance// releases in between:
     11 - **[milestone:0.5]** -> [milestone:0.5.1] -> [milestone:0.5.2].
     12   - **[milestone:0.6]** -> [milestone:0.6.1].
     13     - **[milestone:0.7]** -> [milestone:0.7.1].
     14       - **[milestone:0.8]** -> [milestone:0.8.1] -> [milestone:0.8.2] -> [milestone:0.8.3].
     15         - **[milestone:0.9]** -> [milestone:0.9.1] -> [milestone:0.9.2] -> [milestone:0.9.3] -> [milestone:0.9.4] -> [milestone:0.9.5] -> [milestone:0.9.6].
     16           - **[milestone:0.10]** -> [milestone:0.10.1] -> [milestone:0.10.2] -> [milestone:0.10.3] -> [milestone:0.10.4] -> [milestone:0.10.5].
     17             - **[milestone:0.11]** -> [milestone:0.11.1] -> [milestone:0.11.2] -> [milestone:0.11.3] -> [milestone:0.11.4] -> [milestone:0.11.5] -> [milestone:0.11.6] -> [milestone:0.11.7].
     18               - **[milestone:0.12]** -> [milestone:0.12.1] -> [milestone:0.12.2] -> [milestone:0.12.3] -> [milestone:0.12.4] -> [milestone:next-minor-0.12.x]
     19
     20Starting with the upcoming 1.0 release, we'll make a clear distinction between ''stable'' and ''development'' releases.
     21
     22 - a **major** release (1.//even_number//) is the culmination of the work on a series of development releases; from that point, two new series of minor releases will be started:
     23   - **stable** minor releases (1.//even_number//.x) is for the //maintenance// of the major release; they generally contain bug fixes, no (or only minor) new features; the database model doesn't change, the backward compatibility in the API is strictly observed, etc.
     24   - **development** minor releases (1.//even_number+1//.x) is for //preparing the next major release// using well identified and tested technology preview checkpoints; they contain the great new features, the major refactorings to address design flaws; we allow for breaking API compatibility of the newly introduced features, dropping experimental features, removing stable APIs previously deprecated, etc.
     25
     26In short, users who require a great stability in their use of Trac should follow the //stable// releases, users who want to benefit from the latest features and don't mind following the API changes for their own plugins should use the //development// releases and help us with their feedback to shape the future of Trac!
     27
     28 - Milestones corresponding to //stable// releases:
     29   - [milestone:0.12] -- the previous major release (June 2010), which we're going to support for the foreseeable future (it has earned the **LTS** label, Long Term Support release)
     30     - [milestone:0.12.4] -- the next maintenance release for 0.12.x
     31     - [milestone:next-minor-0.12.x] -- pool of tickets relevant for one of the upcoming minor maintenance releases for 0.12.x
     32   - [milestone:1.0] -- the upcoming major release (July 2012)
     33    - [milestone:next-stable-1.0.x] -- pool of tickets relevant for one of the next minor maintenance releases for 1.0.x
     34 - Milestones corresponding to **development** releases:
     35   - [milestone:next-dev-1.1.x] -- pool of tickets relevant for one of the next minor feature releases,
     36     - starting with [milestone:1.1.1] which will be released shortly after [milestone:1.0], with features which couldn't have make it for 1.0
     37   - [milestone:next-major-releases] -- pool of tickets relevant for one of the next next major feature releases
     38
     39This scheme will enable us to make **stable** and **development** releases in parallel:
     40
     41 - **[milestone:1.0]**
     42   - [milestone:1.0.1] -> [milestone:1.0.2] -> ... -> [milestone:next-stable-1.0.x]
     43   - [milestone:1.1.1] -> [milestone:1.1.2] -> ... -> [milestone:next-dev-1.1.x]
     44     - **[milestone:1.2]**
     45       - [milestone:1.2.1] -> [milestone:1.2.2] -> ... -> [milestone:next-stable-1.2.x]
     46       - [milestone:1.3.1] -> [milestone:1.3.2] -> ... -> [milestone:next-dev-1.3.x]
     47         - ...
     48           - [milestone:next-major-releases]
     49             - ...
     50
     51People won't have to wait for ~2 years for the next major release before using the shiny new features and developers will be motivated to see these features be released more rapidly ;-)
     52
     53Finally, we also have a few milestones which don't correspond to a Trac release:
    1854   - [milestone:unscheduled] - tickets corresponding to valid issues or feature requests but in which the Trac developers have no interest
    1955   - [[milestone:not applicable]] - tickets which relate to Trac, but not directly to a release
     
    2460
    2561== High-level Workflow
    26 Detailed guidelines can be found on each milestone, but here's how things generally work:
    27  - **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
    28  - **major** releases contain the great new features, the major refactorings to address design flaws, and so on
     62Detailed guidelines can be found on each milestone as "//Notes to maintainers//", but here's how things generally work regarding the tickets:
     63 - new tickets have **[query:milestone=&status!=closed 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)//
     64 - if we're in the early period of the stabilization of a major release (e.g. //1.0//, //1.0.1//, //1.0.2//) and the ticket reports a valid //defect//, the ticket will likely go in **[milestone:next-stable-1.0.x]** pool of tickets
     65   - from there (or directly if the triager is also the developer going to fix it), a developer eventually picks it and moves it to the current **1.0.y** minor stable 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, etc.
     66   - the later we are in a stable cycle (//1.0.4//, //1.0.5//, ...), the more unlikely the defect will be fixed part of that cycle, if it's not a critical defect or a security issue
     67 - if it's a proposed feature and we like it, or a minor defect we'll take care to fix one day, the ticket goes into the **[milestone:next-major-releases]** pool (mid or long-term) or  **[milestone:next-dev-1.1.x]** (short-term) 
     68   - from there, a developer eventually picks it and moves it to the current **1.1.y** minor development release, when there's some actual code ahead
     69 - 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 [milestone:unscheduled]; it may eventually move from there to a more concrete milestone depending on the involvement of contributors
     70 - otherwise the ticket is rejected (//wontfix//)
     71 - sometimes, the defect reported is real and serious but we can't actually do something about it because the culprit software is not maintained by us; if the problem is about some tool using Trac (typically a plugin), we'll close the ticket (//cantfix//); if the problem is about some tool used by Trac and we want to monitor what's happening, we keep it open in [[milestone:not applicable]]
    2972
    30 The fate of an individual ticket generally goes along one of the following paths:
    31  - 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)//
    32  - 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
    33    - 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, ...
    34  - 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
    35    - from there, a developer eventually picks it and moves it to the actual **0.1X** major release
    36  - 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
    37  - otherwise the ticket is rejected
     73More details about ticket triaging can be found in the TracTicketTriage page.
    3874
    3975You 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).
     
    4379We're also using the dates as a way to order the milestones.
    4480
    45 
    46 See also SeaChange for a general discussion about what users (and developers) would like to see happening in Trac.
     81Finally, we also prepare for the future development directions in the wiki itself, look in TracDev, for //Development Proposals// and //Development Branches// for a list of such pages.
     82See also SeaChange for a general discussion about what users (and developers) would like to see happening in Trac, as well as the TracDev/ToDo page for the ongoing stuff.