Bazaar developers’ blog

March 25, 2010

poll: how long should we support stable series?

Filed under: Uncategorized — Martin Pool @ 12:39 am

Every six months, the Bazaar team makes a major release, like the recent 2.1.0. This starts a stable series of bugfix-only updates that lasts for at least six months: no format or network changes, minimum chance of regression, and no disruption to plugins or other API clients. The idea is that people can install a major release, perhaps standardize their team on it, and then get fixes but no disruptive upgrades.

We’ve been doing this for just over a year now, and it’s going very well: the point releases are getting into the update channel for Ubuntu, Fedora, and other distros.

Now we have two stable series currently supported, with 2.0.5 and 2.1.1 just recently released, and 2.2b1 coming out at the end of this week.

We’re wondering: how long should we maintain these series, and how often should we do releases from them? On the code side, maintaining multiple branches in Bazaar is pretty easy, but making installers for all platforms, uploading and announcing them does take some work for every release we do.

At the moment I’m leaning towards supporting each of them for at least a year, but perhaps pushing out the interval between bugfix updates on stable branches: perhaps every two months, unless a critical bug is fixed.

What do you think? Are you using, or thinking of using a stable-series release of Bazaar? Would upgrading to a new stable branch every year be realistic? Are you getting bugfixes at about the right rate?


  1. Considering Ubuntu’s relationship with Bazaar, should supported versions match those in supported Ubuntu versions?
    The more I think about it, the more I think that would be a “bad idea”TM
    However, a 18 month support cycle would match regular Ubuntu releases, so that might not be too bad a trade-off.
    I’m currently using the PPA’s so bug fixes come in, for the most part, soon enough for me :-)

    Comment by David — March 25, 2010 @ 3:26 am

  2. Following Ubuntu support seems lika good idea, having to use the PPA to deploy a bzr branch on an Ubuntu server seems lika a lot of work.

    Comment by Daniel Wiberg — March 25, 2010 @ 10:00 am

  3. A 1 year maintainance works pretty well for Fedora. The six month guarantee is superb. Thank you for that!

    I also maintain packages in EPEL (Packages to add functionality to RHEL, CentOS, and derivatives) and there the story is more complex. RHEL has a seven year release lifetime. EPEL strives to make no API/ABI incompatible updates (or mandatory on-disk format changes) in package updates over that lifetime. However, this is not always possible. I just got permission to upgrade from bzr-1.13 to bzr-2.1.1 in EPEL, for instance. The rationale I gave was that, although there are API breaking changes in that upgrade, bzr-1.13 no longer works with launchpad and that’s the compatibility area that we should be more concerned with in this case.

    Getting an updated package like this out to EPEL users is more work for a maintainer as we have to run the rationale by the other packagers to make sure it’s sane, make announcements of our intention to break compatibility to our users, and then take bug reports from users who do not like the choice to upgrade incompatibly after the upgrade is done. However, I view doing it as somewhat inevitable given the fact that repository formats change in bzr and the server can’t always translate between formats on-the-fly. So, what would cut down on my work but would acknowledge this necessity? Ideally, a given bzr branch would be announced as receiving bugfixes for a longer period. That branch would be available as long as launchpad’s repository format was compatible with that version. When launchpad updates to an incompatible format, there’s a new branch that can handle the format that is known to be receiving bugfixes for an extended period, that way we know which branch makes the most sense to switch to.

    Note that this is just an explanation of how a long term distribution’s workflow looks and how to minimize its pain points. Even the update period of the 2.x series is beneficial to a long term distribution’s goals.

    Comment by Toshio Kuratomi — April 12, 2010 @ 4:19 pm

  4. Because bazaar 2.1 doesn’t work with network repositories on Windows, I rolled back to 2.0.4 (latest stable I could find at the time), so I was very happy there was an old stable available that still worked.

    Comment by Perry — May 17, 2010 @ 3:08 pm

  5. (Follow-up: Double-checking, it appears that 2.0.4 is the latest stable for Windows; I was momentarily confused by the above post mentioning 2.0.5.)

    Comment by Perry — May 17, 2010 @ 3:10 pm

  6. I think bzr (and indeed any project) should support a given stable release for as long as any reasonable supported distro that packaged that release is still under support by that distro. You could ignore (or only support this policy for) certain distros if you wish. You could only apply this policy for a given release of a given distro if it packaged the most recent stable release available at the initial release date (i.e. their version selection policy is sane; they don’t package 2-year old cruft).

    (/me who is fed up with other projects who refuse to fix bugs in stable releases shipped with a distro 3 months after the release of the distro when that distro packaged the latest stable release at the time… Just because upstream has released a newer stable release since the distro version shipped)

    Comment by Stephen Warren — June 9, 2010 @ 10:06 pm

RSS feed for comments on this post.

Blog at

%d bloggers like this: