||<>|| = Changes proposed to Series, Milestones and Releases = == Summary == Series, Milestones and Releases provide a very powerful set of tools to manage projects, and we want to evolve it so it's a bit easier for new users to use them, even while not completely understanding how they work. == Goals == * Provide a sane default path for users that induces "best practice" * Visually display the timeline of a project * Simplify creation and gardening == Visualization == See [[https://wiki.canonical.com/Launchpad/UI/Registry/ThreeDotO/Series|proposals and format]] == Example Projects == === Launchpad === Launchpad is the example of a typical Web-based project, which doesn't have tarball releases, always develops on trunk, and doesn't spawn off into series or point releases. {{{ | o-- 2.1.12 | o-- 2.1.11 | o-- 2.1.10 | }}} === Loggerhead === Loggerhead is the example of a small open source project, which doesn't plan ahead, and releases a couple of times a year "whenever it's ready". Releases are used when the actual release is done, version numbers are unknown because they match whatever bzr has at the moment, bugs are targeted to series/milestones, although, exceptionally, it does point releases for major regressions detected after release. {{{ | o-- 1.10 | |\-- 1.6 -- 1.6.1 | o-- 1.0 | }}} === Bazaar === Bazaar is the example of a medium size project, which has monthly releases scheduled. Version numbers are predictable so series and final release milestone are created ahead of time, although the milestones in between are unknown (can have many betas or release candidates). {{{ | |\-- 1.10rc1 -- 1.10 | |\-- 1.9rc1 -- 1.9 -- 1.9.1 | |\-- 1.8b1 -- 1.8rc1 -- 1.8rc2 -- 1.8 | |\-- 1.7rc1 -- 1.7 -- 1.7.1rc1 -- 1.7.1 | }}} === Python === Python is the example of a project with multiple active series in parallel, version numbers are predictable so series and final release milestone are created ahead of time, but, like Bazaar, the milestones in between are unknown. {{{ ____________________________________ / \ | \ |\-- 2.5b1 -- 2.5rc1 -- 2.5 | | |\-- 3.0b1 -- 3.0b2 -- 3.0rc1 -- 3.0 |\-- 2.6rc1 -- 2.6rc2 -- 2.6 | | |\-- 3.1rc1 | }}} === Linux Kernel === The Linux Kernel is the example of a project that always has one active series, version numbers are predictable, but, like the rest, the milestones in between are unknown. It is different in the sense that it's trunk is always called whatever the next version number is. Arguably, this is the case for the rest as well, but is worth considering for special-casing. '''Needs review, it looks like the kernel develops 2 versions in parallel, odd and even-ending versions. See release dates in: http://www.linux.org/''' {{{ }}} === Ubuntu === Ubuntu is the example for a big project which always has one active series, version numbers are predictable, and (in general) all it's milestones are known beforehand. The development focus is always it's current series. There are 3 ways of representing this: '''Option 1:''' {{{ o-- 8.10 | o-- 8.10rc | o-- 8.10beta | o-- 8.10alpha2 | o-- 8.10alpha1 | o-- 8.04 | o-- 8.04rc | o-- 8.04beta | o-- 8.04alpha2 | o-- 8.04alpha1 | }}} '''Option 2:''' {{{ | o-- 8.10 | o-- 8.10rc | o-- 8.10beta | o-- 8.10alpha2 | o-- 8.10alpha1 / / / / | o-- 8.04 | o-- 8.04rc | o-- 8.04beta | o-- 8.04alpha2 | o-- 8.04alpha1 / / / / | o-- 7.10 | o-- 7.10rc | o-- 7.10beta | o-- 7.10alpha2 | o-- 7.10alpha1 }}} '''Option 3:''' {{{ | |\-- 8.10alpha1 -- 8.10alpha2 -- 8.10beta -- 8.10rc -- 8.10 | |\-- 8.04alpha1 -- 8.04alpha2 -- 8.04beta -- 8.04rc -- 8.04 | |\-- 7.10alpha1 -- 7.10alpha2 -- 7.10beta -- 7.10rc -- 7.10 | | }}} == Use Cases == === Project (registry) === * Used to structure development * Used to track releases/downloads ==== Changes proposed ==== * Make releases a status of a milestone (when a milestone is released, it's no longer a milestone) * Track historical information of which series was the development focus at the time * Make dates mandatory for milestones, and email people as the date approaches for them to take action * Allow subscribing to a milestone * Make releases a bit (visually) less tied to downloads, so a milestone can be marked as "released" or "accomplished", without having files attached to it. Currently, it looks like it's missing something. * Rename "series" to "lines of development" === Soyuz === * Used to link packages with releases ==== Changes proposed ==== === Code === * Used to link branches with specific lines of developments or releases ==== Changes proposed ==== * Somewhat related to: [[https://wiki.canonical.com/Launchpad/PackageBranches|Package Branches]] === Bugs === * Used to target bugs (single bug task) * Used to track the status of bugs in different releases (multiple bug tasks) ==== Changes proposed ==== * Allow targeting a bug to a series without creating a separate bug task. Go from [[attachment:current_bug_series.png]] to allowing [[attachment:proposed_bug_series.png]] == Migration == * We currently don't have "main series" or "main lines of development". Those are needed to represent the vertical line * All the features to move/delete any series/milestone/release need to be in place a while before rolling out the visualization, as most project will look broken when we do == Unresolved issues == * What do we do with all the current milestones that don't have dates (most of them don't) * No historical data of what the development focus was