Bazaar spontaneously unusable

[Neil Martinsen-Burrell]

On 03/30/2010 02:28 AM, Martin Pool wrote:
> 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?

I think it's worth a go, but authors will only rely on it if it becomes 
trustworthy.  I have concerns about its scalability as our already large 
plugin ecosystem becomes even larger, particularly as we see more 
closely bound plugins such as those for IDEs (althought qbzr and 
Explorer are decent canaries for such plugins).

>> 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.

As a plugin author whose plugin works on 2.1 but not 2.0 (uses 
BzrCommand.run_direct in the implementation and bzrlib.tests.script in 
the test suite), I like the idea that I could find version 
incompatibilities by running the test suite.  I'm not sure that this is 
the case currently.

I declare bzr_minimum_version = (2,1,0) in my plugin's setup.py and when 
I run ``bzr-2.0 selftest -s bp.colo`` I get skips for almost all of my 
tests.  This is wonderful that this works so easily, but what that 
doesn't take care of is the fact that ``bzr-2.0 colo-branch new_branch`` 
gives an ugly traceback.  Should I be doing api_require for such a 
situation?  Where can I get a mapping from bzr versions to api versions?

The *proper* way to declare version requirements is something that could 
be clearer in our plugin documentation.  If I knew what was proper, then 
I would even be willing to write that documentation.

-Neil