Projects/SeriesMilestonesReleases/Draft

Not logged in - Log In / Register

Revision 9 as of 2008-03-18 10:07:30

Clear message

DRAFT: this page is a work in progress. Please [:Feedback:seek further help] or check the [:TitleIndex:wiki index] for a complete page on this topic.

ContentsBRTableOfContents

Overview

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.

Series

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:

Let's take a look at the [https://launchpad.net/bzr Bazaar] project as an example.

attachment:bzr-timeline.png

Series in the Bazaar project

Here you can see some of the different lines of development from the Bazaar project:

Creating series

To create a series, provided you're either the project's owner or driver, click Register a series in the Actions menu.

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 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 checkout of "trunk" always get the tip of your development, rather than discovering later on that it has turned into a stable release.

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

attachment:bzr-sev-series-overviewtimeline.png

The bzr.dev series overview

Over time, a great deal of useful public information about the history of a project becomes associated with its series. That's why, right now, the only way to delete a project series is to [https://answers.launchpad.net/launchpad/+addquestion make a request with the Launchpad admins].

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' driver.

[https://edge.launchpad.net/beeseek/ BeeSeek] is a project to create an open source peer to peer search engine. BeeSeek's drivers have accepted [https://bugs.launchpad.net/beeseek/+bug/182821 bug 182821] as affecting two of their series, [https://edge.launchpad.net/beeseek/hive Hive] and [https://launchpad.net/beeseek/honeybee Honeybee].

Anyone can nominate a bug or blueprint as affecting a particular series with the Nominate for release link in the Actions menu. However, only the relevant driver can accept it as series goal.

attachment:beeseek-bug.png

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.

Milestones

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:

This is [https://launchpad.net/awn/+milestone/0.4 Avant Window Navigator's 0.4] milestone.

attachment:awn-04.png

Milestone 0.4 for Avant Window Navigator

As you can see, milestones are a really simple way of organising work. Other than a brief description of the milestone's purpose, there's a list of the six blueprints and twenty three bugs targeted to it. Now, everyone working towards AWN 0.4 knows what the release will look like and has the opportunity to volunteer to take some of the work.

Creating a milestone takes no more than clicking Add milestone in the Actions menu for the relevant series. Once the milestone is complete, uncheck Active on its Modify milestone details page. Once deactivated, the milestone no longer appears on your project's overview or milestone pages but is still accessible through its URL.

Releases

While series and milestones help you to plan work that may become a release, they're not particularly accurate ways of recording what actually happened in a release. For example: if you target a milestone with ten bugs and three blueprints for release on 10th June 2008, you may choose to slip some of the work in order to make your target date or you may prefer to delay the release.

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.

Recording a release also allows you to host and distribute the resultant files, such as a binary installer or some documentation.

Next steps

Making those files available for [:Projects/Downloads:download] is what we'll look at next.