• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

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 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: 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 current_bug_series.png to allowing 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