|Version 54 (modified by 17 months ago) ( diff ),|
Trac's Road Ahead
This page gives insight about how past, current and future releases of Trac are organized.
See the roadmap for the list of milestones along with their description. You'll find the currently open Milestones, but you can also use the filter panel at the upper right corner of the page to select "closed milestones" to get an overview of the whole project's life.
The interval between releases can vary quite a bit depending on the availability of developers. Starting from late 2014 we are aiming for a minor release every two months, and a major release every year. This is not guaranteed, but we're optimistic that we can keep to this schedule for a while.
Until 1.0, Trac releases followed a linear sequence of major feature releases, with minor maintenance releases in between:
- 0.5 → 0.5.1 → 0.5.2.
- 0.6 → 0.6.1.
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:
- 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.
- 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.
Stable and development releases happen in parallel:
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:
- unscheduled - tickets corresponding to valid issues or feature requests but in which the Trac developers have no interest
- not applicable - tickets which relate to Trac, but not directly to a release
- translations - tickets used to coordinate the ongoing translation effort
- Some plugins are maintained here:
- Milestones corresponding to stable releases:
- 1.2 — the November 2016 release
- next-stable-1.2.x — pool of tickets relevant for one of the next minor maintenance releases for 1.2.x
- 1.4 — the latest major release (August 2019). It has earned the LTS label: Long Term Support release.
- next-stable-1.4.x — pool of tickets relevant for one of the next minor maintenance releases for 1.4.x
- 1.2 — the November 2016 release
- Milestones corresponding to development releases:
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 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.4, 1.4.1, 1.4.2) and the ticket reports a valid defect, the ticket will likely go in 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 next-major-releases pool (mid or long-term) or 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 unscheduled; it may eventually move from there to a more concrete milestone depending on the involvement of contributors
- otherwise the ticket is rejected (wontfix)
- 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 not applicable
More details about ticket triaging can be found in the TracTicketTriage page.
You can usually influence how a ticket moves from one category to the other by providing the requested feedback, clarifications about the issue or the code you contributed (about code contributions, see PatchWelcome for details).
Note that the planned release dates are not bounding, they should only be taken as an estimation. We're also using the dates as a way to order the milestones.
Finally, we also prepare for the future development directions in the wiki itself, look in TracDev, for Development Proposals and Development Branches for a list of such pages. See also SeaChange for a general discussion about what users (and developers) would like to see happening in Trac, as well as the TracDev/ToDo page for the ongoing stuff.