Not logged in - Log In / Register

Bind branches to product series

Status: Very rough draft. Please edit.

Blueprint: branch-product-series

Currently, branches in upstream projects are bound primarily to that project and in general have no link to a product series. This specification discusses how Launchpad might work if all branches had an associated product series.


Principles (I'd let anyone take over this as long as they... )

Out of Scope


Doris the Python Hacker

Doris wants to get the latest Python source code sos he can see what makes tuples different from lists. She fetches the latest Python:

$ bzr branch lp:python
Fetching bzr+ssh://

Doris notices that there's a terrible lack of unit tests for the unittest module and decides to write some:

$ bzr branch python tests-for-unittest

Eventually she finishes and pushes his branch up to Launchpad:

$ bzr push lp:~doris/python/tests-for-unittest
Pushing to bzr+ssh://

Her branch is now available at:

Wouter the Bazaar developer

Wouter has been working on the Nested branches feature since bzr 1.2. He pushes every sporadically, but never really merges into trunk because he's afraid of reviews.

Wouter has always pushed and pulled from:


BUT, the following canonical URLs have been created:

Bazaar's version in Hardy is 1.3, and Wouter realizes that it has a critical bug which he had a fix at the time, so he wants to create a 1.3.1 release.

He now goes to Launchpad and finds his branch at the 1.3 release, and does:

$ bzr branch lp:~wouter/bzr/1.3/nested-branches

He fixes the critical bug and pushes it back up to Launchpad at lp:~wouter/bzr/1.3/nested-branches, coordinating with the Registry team to figure out exactly how it is that you do a point release anyway.


This leads to a profusion of branches, but if well-managed this is not a problem. First, the primary listings will be on (product, productseries), so at most one version of "nested branches" will appear. After all, the big idea with linking to productseries is to hide branches that are not a part of the current, interesting lines of development.

Ideally, there would be a page, say ~wouter/bzr/nested-branches or ~wouter/bzr/+all/nested-branches that linked to all the series branches where nested-branches occurred. (XXX - haven't thought about how to implement this, seems non-obvious - jml).

Releasing Bazaar

Bazaar releases every month. What happens is that the Release Manager (RM) at some point makes a branch of trunk (aka that the release will ultimately be made from. A tarball is made from this branch and advertised as the release candidate. Meanwhile, Bazaar developers keep making branches from trunk. These branches are considered to be part of the next release.

If a problem is found in the release candidate, the fixing developer branches the release branch, makes his fix and merges it into the release branch.

Ultimately the release is made from the release branch. If a point release is required, further changes will be committed to the release branch and another release made from the branch.

The process

We don't have a branch called "". There is only the series branch for the 1.8 series, which is the current development focus:

(the "*" means that this is the development focus series)

Then, when the release candidate is being made, the RM hits a button that "clones" this line of development (and the associated Bazaar branch), with the option to make the new series the development focus.

In many cases, the OLD and NEW branches would be identical. However it's possible that the RM might wish to designate a particular non-tip revision as the start of the 1.8 series.

Note that the canonical name of the series branch is /bzr/1.8. In this way, the main branch of a product series becomes like the official source package branch, described in PackageBranches.

Wouter & Jelmer

Wouter last pushed his nested-trees up to Launchpad during the 1.9 cycle. Since then, 1.9 has been released and the 1.10 series has been opened and is the development focus.

Jelmer decides to see what he can do to make nested trees happen. He branches from lp:~wouter/bzr/nested-trees and gets Bazaar's equivalent of a 404.


The "development focus" property is actually sticky on a branch. That is, ~bzr/bzr/ is always the development focus. Given that our data model goes product -> anointed series -> anointed branch, this is a bit crap.

Within a line of development, there are two sorts of branches:

  1. The branch that *is* the line of development (in some sense). This branch tends to be long-lived. This information is already stored in the database.
  2. Branches that are *intended for* a specific landmark on a line of development (which could be the horizon). This branch tends to be short-lived. We kind of store this with merge proposals -- perhaps we can make a bigger deal out of that?

ACTION: Talk to MySQL about the productseries-branch thing. This affects all our users and we should get their input, but MySQL are perhaps one of the most active and major non-Canonical users.

To Do

BranchProductSeries (last edited 2008-11-20 06:30:05 by jml)