I have a bit of a quandry with the bzr package in EPEL I want to upgrade it due to compatibility problems but the upgrade brings in abackwards compatibility problems. Let me explain::
bzr is a distributed version control system. The main hosts of bzr repositories that we care about are launchpad and fedorahosted.org. People can, of course run their own repositories. The version of bzr in EPEL is 1.3.1 The version of bzr in F-12 is 2.0.5. The version of bzr in F-13/rawhide is bzr-2.1; bzr-2.2 is just around the corner (so likely going into F-14) There are three places where compatibility can be broken in the version control system: 1) The on-disk repository format 2) The on-the-wire protocol between the client and server. 3) The API -- bzr provides a python module on which other tools can be built as well as plugins to bzr The repository formats supported by bzr-1.3 are a subset of the formats supported by 2.1. This means that there's no backwards incompatibility concerns with upgrading to bzr-2.1. But there is a forwards compatibility issue where repositories on launchpad and in other projects are not usable with the bzr client we ship. This is an impetus for upgrading as the current EPEL clients will not work with launchpad. The on wire protocol has been upgraded over time. There are fallbacks so that, for instance, the bzr-2.0 client is supposed to work with a bzr-1.3 server. However, there is one or more bugs in the bzr-2.1 client that's causing it to not work with the 1.3 server. This means that the Fedora 13 bzr client cannot talk to the server on fedorahosted. There currently is no sign of a patch for the problem. This just leaves the API. The API of bzr continuously evolved during the 1.x series (and before). Typically, incompatible changes were announced with six month lead time and then any compatibility layer was removed. If one change was announced in January and another in February, that meant that June and July would both have incompatible releases. This deprecation style was okay for developers as it allowed them six months to port their stuff forward but was chaos for distributors like us. A few of us raised the issue upstream and starting with bzr-2.0 a different style was adopted. 2.x.y contains no incompatible changes when a new .y releases (barring secuirty holes that can only be plugged with API changes). The support cycle of a 2.x release is 6-12 months (1.x and before had a 1 month cycle). New 2.x releases may break API but the justification needs to be that it makes things better for the bzrlib API. This usually means that porting should be straightforward. Plugins and code written for bzr that is currently in Fedora and EPEL all have versions that run on the latest bzr-2.x (2.1). Of the tools in EPEL, none of the versions we're carrying (that run on bzr-1.x) are still supported by upstream. Tools that are either locally written or not maintained upstream may be written for bzr-1.x and will not run on bzr newer than the bzr-1.13 that we have in EPEL ATM. This is the case with Fedora Infrastructure's use of bazaar-webserve, for instance. Upstream development on it has stopped and it won't run with anything newer than bzr-1.13. This is something of a chicken and egg problem, however, as loggerhead, the new bzr web viewer won't run with bzr-1.13 so there's been no ability to move off of it without rebuilding the bzr-2.x stack locally (something I'm in the process of doing since EPEL's bzr server isn't compatible with F-13's client). Ubuntu Lucid (the upcoming long term service release) is going to ship with bzr-2.1.x. Because it is supported for 3 years on the desktop and 5 years on the server, I'm guessing that they will upgrade to bzr-2.2, 2.3, 2.4, etc over the lifetime of the product but they could choose to backport fixes to bzr-2.1 instead. So what's this mean for us? It means that I'd like to update EPEL's bzr to the 2.1 branch. This breaks API compatibility but it has the following benefits: * It brings us over-the-wire compatibility with bzr-2.x * It brings us repository format compatibility with current bzr-2.x users so they can share their repositories with users of the EPEL packages * It brings us a client that can talk to launchpad, probably the most important source of bzr repositories if you're an open source developer. So what do other people think here? Is the over-the-wire and repository-format compatibility issues sufficient to override the API compatibility issues in this case? As the maintainer, I definitely believe so but I await your input. Thanks, -Toshio
pgpsrI46OGiXH.pgp
Description: PGP signature
_______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
