• 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

Milestones are a handy way to keep track of bugs or features that you plan to get sorted by a specific date or point in your development cycle. They are lightweight - a project team might put out a new milestone every week or two during a six month development cycle, for example.

Blueprint lets you record that you want a particular specification to be done in a particular milestone. There is no real approval process - if you are related to the spec, you can set the milestone, and the spec will then show up on the milestone page. So use this as a short-term way of mapping out which features you want to get done at a particular point in the process.

Typical usage

When we start a major release planning process, we create the Product Series in Launchpad, call that "2.0" for example. Then we figure out roughly what sorts of milestones we will want for the major points of the 2.0 series. An example would be:

• 1.9a1
• 1.9a2
• 1.9a3
• 1.9b1
• 1.9b2
• 2.0rc1
• 2.0rc2

In the case of Ubuntu, we use codenames for the milestones, so for example in Dapper we might have planned the following (if we had all this in place at the beginning of Dapper):

• Flight1
• Flight2
• Flight3
• Flight4
• Flight5
• Flight6
• 6.06beta
• 6.06rc1
• 6.06-LTS-rc2

Now, we also plan out all the feature goals for the major release. These get nominated by the developer team, and approved by the drivers (see BlueprintGoalManagement) so that we can see exactly what we are shooting for. At this stage, we might start to identify which features we want to land early, and which we expect to land later. We can start to target those to milestones, but this process is not nearly as rigorous as the series targeting which makes up our formal release management. In general, the top devs will point a couple of specs at each milestone, and then individual devs will drop their own feature goals to the milestones they think are appropriate.

Of course, the Blueprint roadmap feature helps us keep that roughly in alignment.

The net result is that over time, a picture emerges of what features we expect to land when. The milestones are not cast in stone, we often miss a feature goal or two and there is no hard-core process to follow up when that happens. So milestone tracking is lightweight, individual developers use it for their own planning purposes without the central governance associated with series targeting.