| 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 | |
| | 10 | Until 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 | |
| | 20 | Starting 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 | |
| | 26 | In 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 | |
| | 39 | This 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 | |
| | 51 | People 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 | |
| | 53 | Finally, we also have a few milestones which don't correspond to a Trac release: |
| 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 |
| | 62 | Detailed 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]] |
| 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 |
| | 73 | More details about ticket triaging can be found in the TracTicketTriage page. |
