API incompatible bzr update

Toshio Kuratomi a.badger at gmail.com
Mon Apr 12 00:00:44 UTC 2010


Greetings all,

As the bzr maintainer in EPEL I've been talking to people about updating our
bzr version control system stack to the latest version (bzr-2.1.x).  The
latest version is API incompatible with the current version in EPEL
(bzr-1.13) which would normally be frowned upon.  In this case, however,
there are a few other compatibility concerns that seem to outweigh this:

* The bzr version shipping in Fedora 13 and the Ubuntu Lucid release has
  some issues when talking to older bzr servers.  This means that the new
  clients on those distributions would be unable to talk to bzr servers
  using the EPEL-5 packages.  Although this is a bug, upstream doesn't yet
  have a patch for this so it could be quite a while before an update comes
  out that allows those clients to talk to old servers.
* The bzr package in EPEL-5 is not able to talk to launchpad because the
  on-disk repository format that launchpad uses is not available to the bzr
  client in EPEL.  This means that people running the bzr client we ship in
  EPEL are not able to share repositories with launchpad, arguably the most
  important bzr hosting service.

The API incompatibility in the bzr package means that when we upgrade,
third-party modules could be broken.  This involves bzr plugins that are no
longer maintained upstream and bzr plugins that may have been written
locally to address a local need.  Weighed against this is the ability for
other third party plugins written and maintained against the current bzr
APIs to be built and run once we upgrade.

The impression I have and reason that I asked for leave to make this
update, was that there are few plugins being used that fall into these
categories and that updating to a version of bzr that can work with
launchpad, Fedora 13, and the new Ubuntu release are more desirable than
breaking these few plugins.  If I'm wrong and many of you do depend on the
bzr API remaining stable, please speak up so that I don't proceed with this
plan.

I'll be building updated packages for bzr and the other epel-5 bzr-related
packages (bzrtools, bzr-gtk, qbzr, loggerhead) this week and pushing them
into epel-testing.  They'll sit there for a minimum of two weeks and if
there's not an overwhelming outcry that this update should not be performed,
they'll then go to the epel-stable repository for all to consume.

I hope that we can work to fit the majority of people's needs,

-Toshio Kuratomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20100411/4edf35e2/attachment.sig>


More information about the epel-devel-list mailing list