Linking project releases in Launchpad to milestones

In our 2.2.3 release of Launchpad — due 1st of April — we’re strengthening the relationship between milestones and releases.

Project releases will be explicitly linked to a milestone, meaning the release inherits the milestone’s series and identity information.

You’ll be able to create a new release from a milestone page or, if you don’t yet have a milestone, there’ll be an option to create a release and its parent milestone simultaneously. You can still have milestones that do not correspond to releases.

Just as now, the release will hold the release notes, changelog, date released, and any downloadable files.

What are Releases, Milestones, and Series?

Launchpad hosted projects can arrange their development into Series, which contain Milestones to which bugs can be targeted, and Releases which hold download tarballs and have release notes. Although Milestones and Releases go together, they were previously managed separately in Launchpad. Now they’re more unified.

Why are we doing this?

Many people already use releases and milestones in this way. Milestones aid release planning, and help people understand a project’s goals. Creating a release directly from a milestone implies that the milestone was reached.

Linking milestones to releases improves the data consistency between projects. With good milestone and release information, Launchpad can improve the presentation of series to explain what has happened, and what will happen. We hope that this will make it easier for people to know where and when to make contributions to your project.

This change also allows us to redesign the series, milestone, and release pages. Our goal is to better present the history and future of a project, as well as to improve the workflow for planners.

What you can do

You do not need to take any action regarding releases. We’re migrating existing releases by linking them to a milestone, or if there isn’t an appropriate milestone, creating a new one.

You can use Launchpad’s staging environment — — right now to check what your releases
and milestones will look like under the new system.

We’d value your feedback so we can improve the data migration script. If you come across a problem, please report a bug here:

For other comments, send us an email to

How we’re making the migration

The release’s project, project series, version, code name, and summary come from the milestone it’s linked to. The release’s version will come from the milestone’s name.

When a release and a milestone share the same series and version/name, they are linked. The release’s summary will be appended to the milestone’s summary. You should review your project’s milestones. You can make changes to your project’s milestones and releases on to ensure they are merged correctly on before the final migration.

When no milestone can be matched to a release, a new milestones is created from the release’s information. The milestone is not active, they will only appear on the project’s milestone page. There are a few instances where two series have a release of the same name. Milestone names are unique across a project. So the milestone’s name will contain the release’s version and series name (0.9-series-trunk). You can prevent this from happening by renaming some of your project’s releases on now — in most cases, the duplicate release name is on an obsolete series, or trunk. You can view all your projects series at:<your-project>/+series

We’re also taking the opportunity to rename a couple of things: description” becomes “summary” and the milestone’s visibility flag (in the REST API) is renamed to “active”.

We believe this change will make releases and milestones much more useful. Please do report bugs or email us if you have any comments.

Leave a Reply