Edgewall Software

Changes between Version 53 and Version 54 of RoadMap


Ignore:
Timestamp:
Aug 27, 2019, 1:59:01 AM (3 months ago)
Author:
Ryan J Ollos
Comment:

Rework page for upcoming releases.

Legend:

Unmodified
Added
Removed
Modified
  • RoadMap

    v53 v54  
    2222               - **[milestone:0.12]** -> [milestone:0.12.1] -> [milestone:0.12.2] -> [milestone:0.12.3] -> [milestone:0.12.4] -> [milestone:0.12.5] -> [milestone:0.12.6] -> [milestone:next-minor-0.12.x]
    2323
    24 Starting with the upcoming 1.0 release, we'll make a clear distinction between ''stable'' and ''development'' releases.
     24Starting with the 1.0 release, we make a clear distinction between ''stable'' and ''development'' releases.
    2525
    2626 - 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:
     
    2828   - **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.
    2929
    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:
    4531
    4632 - **[milestone:1.0]**
     
    4935     - **[milestone:1.2]**
    5036       - [milestone:1.2.1] -> [milestone:1.2.2] -> ... -> [milestone:next-stable-1.2.x]
    51        - [milestone:1.3.1] -> [milestone:1.3.2] -> ... -> [milestone:next-dev-1.3.x]
     37       - [milestone:1.3.1] -> [milestone:1.3.2] -> ... -> next-dev-1.3.x
    5238         - ...
    5339           - [milestone:next-major-releases]
    5440             - ...
    5541
    56 People won't have to wait for ~1-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 ;-)
     42In 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!
    5743
    5844Finally, we also have a few milestones which don't correspond to a Trac release:
     
    6450     - [[milestone:plugin - spam-filter]]
    6551
     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
    6664== High-level Workflow
     65
    6766Detailed guidelines can be found on each milestone as "//Notes to maintainers//", but here's how things generally work regarding the tickets:
    6867 - 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)//
    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
    7473 - 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
    7574 - otherwise the ticket is rejected (//wontfix//)