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.

Overview

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

• Series: parallel lines of development within your project, working towards a major release.

• Series goals: bugs or blueprints that will be fixed in a particular series.

• Milestones: points in the development of a series, such as future minor releases or release candidates.

• Releases: previous releases within a series.

Launchpad doesn't impose a particular workflow on your project, so how and whether you use these depends on what value you feel they'll bring.

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:

• Development trunk: this is the current "tip" of development across the core project community, representing the very cutting edge of work on that project. In general, the only releases made from the development trunk are snapshot, milestone or test releases to generate more widespread testing and feedback.

• Stable and supported branches: these represent the latest work on the stable versions of the project, which are still supported. If updated stable releases are to be made they will come from these branches.

• Obsolete branches: for major release versions that are now out of date and no longer updated. It's likely that work no longer happens on these branches.

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:

• branches of code
• bugs marked as affecting that series
• bugs and blueprints proposed as goals for the series
• translation effort
• milestones - specific points in the roadmap
• releases
• driver - in effect a release manager.

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

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

• bzr.dev: the current line of active development and source of snapshot test releases for the next stable version.

• 1.3: the latest stable version recommended to new users.

• 1.2, 1.1, 1.0: previous lines of development that produced releases.

Naming series

It's up to each project what a series represents and what naming convention they 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.

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: branch from trunk, create the series and link the branch to that series. This ensures that people who create a checkout of "trunk" don't find that it goes stale because it has later become a stable series.

When you register a series, the description you give it tells other people what your intentions are. If we look at Bazaar's bzr.dev series overview page we can see that it's described as "...the development mainline where new releases are published".

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 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 marked [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].

As you can see, this bug has a separate importance, status and assignee in each series. Launchpad excels at tracking how an individual bug affects different communities and contexts; we'll see more of that later.

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. As they require official project approval, you may choose to use series goals as a commitment to implement a fix or feature in a particular release.

Milestones

If series are lines of development, from which releases are made, milestones are specific points on the road to that release, such as:

• beta tests
• release candidates
• minor point releases.

Just like series themselves, you can target individual bugs and blueprints to a particular milestone. However, they differ in a couple of important ways:

• anyone can target a bug or blueprint to a milestone: no approval is required
• milestones exist within the series - i.e. there's no option for separate status, important and assignee.

This makes them an ideal, lightweight, way to group a number of bugs and blueprints, targeted to a particular date.

This is Avant Window Navigator's 0.4 milestone.