30 | | 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! |
31 | | |
32 | | - Milestones corresponding to //stable// releases: |
33 | | - [milestone:0.12] -- the June 2010 release, which we're going to support for the foreseeable future (it has earned the **LTS** label, Long Term Support release) |
34 | | - [milestone:next-minor-0.12.x] -- pool of tickets relevant for one of the upcoming minor maintenance releases for 0.12.x |
35 | | - [milestone:1.0] -- the July 2012 release |
36 | | - [milestone:next-stable-1.0.x] -- pool of tickets relevant for one of the next minor maintenance releases for 1.0.x |
37 | | - [milestone:1.2] -- the latest major release (November 2016) |
38 | | - [milestone:next-stable-1.2.x] -- pool of tickets relevant for one of the next minor maintenance releases for 1.2.x |
39 | | - Milestones corresponding to **development** releases: |
40 | | - [milestone:next-dev-1.3.x] -- pool of tickets relevant for one of the next minor feature releases, |
41 | | - starting with [milestone:1.1.1] which was released shortly after [milestone:1.0], with features which didn't make it for 1.0 |
42 | | - [milestone:next-major-releases] -- pool of tickets relevant for one of the next next major feature releases |
43 | | |
44 | | This scheme will enable us to make **stable** and **development** releases in parallel: |
| 30 | **Stable** and **development** releases happen in parallel: |
| 52 | == Upcoming Milestones |
| 53 | |
| 54 | - Milestones corresponding to //stable// releases: |
| 55 | - [milestone:1.2] -- the November 2016 release |
| 56 | - [milestone:next-stable-1.2.x] -- pool of tickets relevant for one of the next minor maintenance releases for 1.2.x |
| 57 | - [milestone:1.4] -- the latest major release (August 2019). It has earned the **LTS** label: Long Term Support release. |
| 58 | - [milestone:next-stable-1.4.x] -- pool of tickets relevant for one of the next minor maintenance releases for 1.4.x |
| 59 | - Milestones corresponding to **development** releases: |
| 60 | - [milestone:next-dev-1.5.x] -- pool of tickets relevant for one of the next minor feature releases, |
| 61 | - starting with [milestone:1.5.1] which was released shortly after [milestone:1.4], with features which didn't make it for 1.4 |
| 62 | - [milestone:next-major-releases] -- pool of tickets relevant for one of the next next major feature releases |
| 63 | |
69 | | - 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 |
70 | | - 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.x** 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. |
71 | | - 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 |
72 | | - 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.3.x]** (short-term) |
73 | | - from there, a developer eventually picks it and moves it to the current **1.1.x** minor development release, when there's some actual code ahead |
| 68 | - if we're in the early period of the stabilization of a major release (e.g. //1.4//, //1.4.1//, //1.4.2//) and the ticket reports a valid //defect//, the ticket will likely go in **[milestone:next-stable-1.4.x]** pool of tickets |
| 69 | - 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.4.x** 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. |
| 70 | - the later we are in a stable cycle (//1.4.4//, //1.4.5//, ...), the more unlikely the defect will be fixed part of that cycle, if it's not a critical defect or a security issue |
| 71 | - 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.5.x]** (short-term) |
| 72 | - from there, a developer eventually picks it and moves it to the current **1.5.x** minor development release, when there's some actual code ahead |