Bazaar spontaneously unusable

[Martin Pool]

On 30 March 2010 18:16, Ian Clatworthy <ian.clatworthy at canonical.com> wrote:

>> So the problem is when bzrlib is newer than the plugin and therefore the
>> plugin code can't really have any good idea whether it will work with it
>> or not. It has to just assume
>
> 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.

Right, or at least in the worst case we will take care of giving a
clean message and recommending an upgrade.

>> Some concrete suggestions then:
>>
>> * Put into bzrlib a blacklist of plugin versions known _not_ to work
>> with this version of bzr;
>
>> we only need to add to this list when a problem is discovered; after the
>> plugin fixes the problem they need only bump their minor number.
>
> +1 from me on this idea.

https://bugs.edge.launchpad.net/bzr/+bug/551472 for this.

If we did it, would plugins rely on it and only check the minimum api
version?  Or do authors think it's at least worth a go?

> We run some static analysis scripts over the set of registered plugins and
> get some hard data about exactly what modules and APIs within bzrlib are
> used and by whom. Before we deprecate stuff in the code, we check that
> data/web-site and react accordingly. We might decide not to deprecate
> certain things. Or we might proactively communicate with the plugin
> maintainer about the change and synchronise releasing a new version of the
> plugin with landing the change into bzr's trunk. Either way, I feel it would
> show plugin authors that we care and, equally importantly, keep things
> running smoother for end users.

We can also just run the plugins' tests...  My impression is that a
large fraction of failures are not going to be caught by static
checks; on the other hand some gui code may not have good automatic
test coverage.

How about running pylint across some plugins for example?

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