Packaging Bazaar

[Martin Pool]

2009/7/5 Toshio Kuratomi <a.badger at gmail.com>:
> Old versions (I believe 1.3) of bzr, bzrtools, and bzr-gtk are available
> for RHEL/CentOS via the EPEL repository
>
> http://fedoraproject.org/wiki/EPELhttp://fedoraproject.org/wiki/EPEL/FAQ#howtouse
>
> I want to update to newer versions but unfortunately API keeps changing
> so it's very hard to make sensible updates for an enterprise-class
> distribution.

I think basically you should look at bzr and its plugins as being
locked together: API stability is to make things a bit easier for
plugin authors so they don't need to update immediately, not so that
you can install much newer plugins on older bzrs or vice versa.  If
you want a newer bzr-gtk, you need a newer bzr.  We try to make that
upgrade safe by keeping format and network compatibility.

We can try changing things to make longer-term support easier.  Even
though Ubuntu cycles faster than RHEL, we still find that many users
are on the version of bzr that shipped in the last Ubuntu release.
And this is reasonable - unless you're a pretty active user or being
bitten by some particular bug you probably don't want to upgrade more
frequently than every six months, particularly if you have a whole
development team.

I think doing our main development on a frequently roughly-time-based
cycle is good.  It gets feedback to the developers quickly, it gets
bug fixes out to users quickly once they're written, and it means
there is not much overhead or churn specifically generated by doing a
release.

The default position at present is that distros will ship whatever is
current at the time they freeze.  This is simple but has some arguable
drawbacks:

 * distributors may wish for guidance as to which to pick
 * various distributions released in the same month may have very
different bzr versions
 * the only way we ship bug fixes is as new releases that also add new
features -- well, and we also have those bug fixes on individual
branches, so they can be merged, but the work is on the distributor

We could hypothetically say that we will do a x.0 release every 6-12
months, and then promise to do x.0.y releases that fix serious bugs in
it, so that it can be a stable platform.  I'm not sure this is really
enough because people disagree about which bugs are worth upgrading.

> Fedora is on the latest version thanks to Henrik Nordström who took over
> updating of the packages from me earlier this year.  Currently bzr-gtk
> is broken as the latest version is not compatible with the latest bzr (I
> could package a checkout but in order to build, the checkout requires
> the bzr-stats plugin which is not yet available.)

This is a somewhat separate problem that bzr-gtk needs to release their tip.

-- 
Martin <http://launchpad.net/~mbp/>