Changes between Version 53 and Version 54 of RoadMap

Timestamp:

Aug 27, 2019, 1:59:01 AM (4 years ago)

Author:

Ryan J Ollos

Comment:

Rework page for upcoming releases.

RoadMap

@@ -22 +22 @@
                - **[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]
 
-Starting with the upcoming 1.0 release, we'll make a clear distinction between ''stable'' and ''development'' releases.
+Starting with the 1.0 release, we make a clear distinction between ''stable'' and ''development'' releases.
 
  - 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:
@@ -28 +28 @@
    - **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.
 
-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!
-
- - Milestones corresponding to //stable// releases:
-   - [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)
-     - [milestone:next-minor-0.12.x] -- pool of tickets relevant for one of the upcoming minor maintenance releases for 0.12.x
-   - [milestone:1.0] -- the July 2012 release
-    - [milestone:next-stable-1.0.x] -- pool of tickets relevant for one of the next minor maintenance releases for 1.0.x
-   - [milestone:1.2] -- the latest major release (November 2016)
-    - [milestone:next-stable-1.2.x] -- pool of tickets relevant for one of the next minor maintenance releases for 1.2.x
- - Milestones corresponding to **development** releases:
-   - [milestone:next-dev-1.3.x] -- pool of tickets relevant for one of the next minor feature releases, 
-     - starting with [milestone:1.1.1] which was released shortly after [milestone:1.0], with features which didn't make it for 1.0
-   - [milestone:next-major-releases] -- pool of tickets relevant for one of the next next major feature releases
-
-This scheme will enable us to make **stable** and **development** releases in parallel:
+**Stable** and **development** releases happen in parallel:
 
  - **[milestone:1.0]** 
@@ -49 +35 @@
      - **[milestone:1.2]**
        - [milestone:1.2.1] -> [milestone:1.2.2] -> ... -> [milestone:next-stable-1.2.x]
-       - [milestone:1.3.1] -> [milestone:1.3.2] -> ... -> [milestone:next-dev-1.3.x]
+       - [milestone:1.3.1] -> [milestone:1.3.2] -> ... -> next-dev-1.3.x
          - ...
            - [milestone:next-major-releases]
              - ...
 
-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 ;-) 
+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!
 
 Finally, we also have a few milestones which don't correspond to a Trac release:
@@ -64 +50 @@
      - [[milestone:plugin - spam-filter]]
 
+== Upcoming Milestones
+
+ - Milestones corresponding to //stable// releases:
+  - [milestone:1.2] -- the November 2016 release
+   - [milestone:next-stable-1.2.x] -- pool of tickets relevant for one of the next minor maintenance releases for 1.2.x
+  - [milestone:1.4] -- the latest major release (August 2019). It has earned the **LTS** label: Long Term Support release.
+   - [milestone:next-stable-1.4.x] -- pool of tickets relevant for one of the next minor maintenance releases for 1.4.x
+ - Milestones corresponding to **development** releases:
+  - [milestone:next-dev-1.5.x] -- pool of tickets relevant for one of the next minor feature releases, 
+   - starting with [milestone:1.5.1] which was released shortly after [milestone:1.4], with features which didn't make it for 1.4
+  - [milestone:next-major-releases] -- pool of tickets relevant for one of the next next major feature releases
+
 == High-level Workflow
+
 Detailed guidelines can be found on each milestone as "//Notes to maintainers//", but here's how things generally work regarding the tickets:
  - 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)//
- - 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
-   - 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.
-   - 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
- - 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)  
-   - 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
+ - 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
+   - 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.
+   - 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
+ - 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)  
+   - 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
  - 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 
  - otherwise the ticket is rejected (//wontfix//)