Not logged in - Log In / Register

Launchpad Help > Projects > Series, milestones and releases


Let's look at how you can use Launchpad to plan your project's development and to record releases:

Launchpad doesn't impose a particular workflow on your project, so you can pick and choose how you use Launchpad's development and release planning.

How bugs and blueprints are targeted is largely determined what you need to plan, and how the work is supported when the goal is complete. You can answer the question for yourself by exploring three axes that represent the destination, the journey, and continuity. Most projects favour one side of each axis, but will always use the other side when needed.


When we think of the way a project organises itself, there are major lines of development from which releases are "cut". Typically these lines of development represent:

We call each of these "major" lines of development a "series" because they represent a series of releases of the same major version.

In Launchpad, each series behaves almost like a sub-project, having its own:

For an example, take a look at the Bazaar project. There you'll see a number of series each with their related milestones and releases.

Project maintainers and drivers can register series. When a driver registers a series, the user is also set as the series release manager. Project maintainers and series release managers can create and manage milestones and releases.

Destination axis: Leading or trailing series?

A trailing series is created after the work is completed.

A leading series is created before the work is complete.

Creating series

To create a series, provided you're either the project's owner or driver, click Register a series in the Series and milestones section of your project overview page.

Different projects have different ideas of what a series represents and what naming convention to use. For example, in the GNOME project, the "development trunk" is a series with an odd version number, such as 2.17. When it is ready for release, it is branched with an "even" version number, such as 2.18. Once GNOME make the stable release, they branch it to create 2.19, the new "trunk".

Sometimes, projects also call the trunk "MAIN", a term from the days of CVS.

You can name and use your series however you choose in Launchpad. However, for convention, we suggest you follow the trailing series model. We encourage you to call your project's development focus "trunk" and to use that same branch for development over time. When creating a new stable series, such as the line of development for your next major release, we suggest you:

This ensures that people who create a branch of "trunk" always get the tip of your development, rather than discovering later on that it has turned into a stable release.

This last point is not entirely true, Launchpad + Bazaar allows projects to use leading series without the need to rebranch the focus of development. You can choose the series that is the focus of development. This changes were lp:<your-project> points to. Anyone who branches or pulls using the short-hand URL will always get the branch associated with the focus of development series.

You can tell people the purpose of each series with a short description. Bazaar's series overview page shows that it's described as "...the development mainline where new releases are published".


Milestones are specific points during the life of a series, such as:

They're an ideal lightweight way to group a number of bugs and blueprints, optionally targeted to a particular date. Just like series themselves, you can target individual bugs and blueprints to a particular milestone. However, they differ in a couple of important ways:

Milestones naturally lead to releases. Once the software associated with the milestone is released, you can turn that milestone into a release in Launchpad.

Journey axis: Time-directed or feature-directed milestones?

A time-directed milestone restricts development by time.

A feature-directed milestone restricts development to a feature.

Working with milestones

You can use both kinds of milestones to plan your series.

Series goals

As series tend to represent planned releases, it's useful to target bugs and blueprints to particular series. These are called series goals and must be approved by either the project or that series' release manager.

BeeSeek is a project to create an open source peer to peer search engine. BeeSeek's drivers have accepted bug 182821 as affecting two of their series, Hive and Honeybee.

Only the bug supervisor for a project can nominate a bug or blueprint as affecting a particular series with the Nominate for release link.


Series goal for Hive and Honeybee in BeeSeek

As both these series represent separate code bases, implementing a bug fix in them may fall to different people. It's also likely that the bug will have a different implementation status and importance in each series. As you can see in the BeeSeek example, Launchpad tracks separate importance, status and assignee information for the same bug in each series. BeeSeek have chosen not to fix the bug in their Hive series but Andrea Corbellini has already committed a fix in the Honeybee series.

Launchpad excels at tracking how an individual bug affects different communities and contexts; we'll see more of that later in this guide.

Continuity axis: Continuous or discrete goals?

Continuous goals are project goals to exist beyond the life of a series.

Discrete goals belong to the series and they are not important after the series.

Problems when targeting work to a series


Launchpad helps you to record and publicise the actual details of your release, such as its release date and changelog. Each release shows up in the timeline on your project's Launchpad home page, providing a historical record of what happened and when.

Next step

Making those files available for download is what we'll look at next.

< Registering a project

Publishing files for download >

Projects/SeriesMilestonesReleases (last edited 2012-07-11 16:11:30 by pool-108-28-25-212)