Bazaar spontaneously unusable
Aaron Bentley
aaron at aaronbentley.com
Fri Apr 9 00:39:37 BST 2010
On 03/30/2010 03:16 AM, Ian Clatworthy wrote:
> Right. But *I* feel our plugins authors *ought* to assume that future
> versions of bzrlib will work, not fail. Having being burnt in the past,
> I can appreciate why they are being pessimistic, but lots of plugins
> suddenly spewing out scary messages - or breaking altogether - every 6
> months isn't the right end result. Our job as core developers is to give
> plugin authors every reason to be optimistic that, if their plugin works
> now, it will also work with future versions of bzrlib.
I feel quite justified in my pessimism. I'm currently maintaining three
branches of bzr-pipeline: 2.0, 2.1, and 2.2, because each requires a
different version of the API.
For bzr-pipeline, I extracted cmd_merge.get_merger_from_uncommitted, and
not long afterward, its signature was changed without updating the
minimum API version.
Pretty much every release of bzr breaks Launchpad, so we have a buildbot
that tests compatibility nightly.
I still don't feel comfortable saying something is compatible until I've
tested it.
bzrtools is a counterexample-- perhaps this is because most of its code
is old, and so the APIs it uses are old and more likely to be stable.
Anyhow, every 6 months is a lot better than every month, and these
issues only affect people who aren't using packages, so it's not as bad
as it used to be.
>> * Put into bzrlib a blacklist of plugin versions known _not_ to work
>> with this version of bzr;
Or alternatively, we could whitelist plugin versions known to *work*
despite having been designed for earlier versions of the API.
Maybe instead of trying to stop plugins from aborting on API checks, we
should look at providing a smoother upgrade experience that will prevent
Russel's original problem by upgrading the plugins, or preventing the
upgrade, or disabling the plugins, at the user's discretion.
Aaron
More information about the bazaar
mailing list