API breakages - file bugs / update HACKING.txt ?

Toshio Kuratomi a.badger at gmail.com
Wed May 14 01:20:32 BST 2008

Jelmer Vernooij wrote:
> In order to make life easier for myself as bzr-svn maintainer and for
> its various packagers, I would like to get rid of the (currently very
> strict) coupling of bzr-svn and Bazaar releases.
> bzr-svn only uses public Bazaar APIs but the ones it uses are not used
> by many other plugins and at least one breakage (without deprecation)
> happens each Bazaar release (Bazaar 1.2 being the only exception),
> despite HACKING.txt saying there is a commitment to 6 months API
> stability. Is this still the intention for all public APIs? 
> I realize that there is overhead in deprecating rather than directly
> removing APIs and so it makes not to deprecate when the API is not used
> by any plugins. I could file bugs (before bzr releases) whenever bzr-svn
> uses an API that wasn't properly deprecated so it can be fixed before
> the release. 
> If HACKING.txt is outdated, what is the current policy wrt API breakage?

I didn't realize that policy existed but it has the potential to help 
distro packagers.  Of course, there's two ways to interpret that stability:

1) Every six months, public API changes can be made.
2) After six months of deprecation, a piece of public API can be changed.

The first is much nicer for packagers as it means they have six months 
of releases that they can include and know there won't be API breakage 
that they have to consider when deciding whether to upgrade the packages 
in a stable release.

Assuming of course that this is a goal that bzr will start striving to 
meet :-)


More information about the bazaar mailing list