Changes between Version 47 and Version 48 of RoadMap

Timestamp:

Jul 12, 2012, 11:53:05 AM (12 years ago)

Author:

Christian Boos

Comment:

.y → .x

RoadMap

@@ -63 +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)//
  - 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.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.
+   - 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.1.x]** (short-term)  
-   - 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
+   - 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 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//)