Bazaar spontaneously unusable

[Martin Pool]

On 31 March 2010 06:06, Neil Martinsen-Burrell <nmb at wartburg.edu> wrote:

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

There are a few possibilities when running the tests:

 1- expected to work, does work - passes - great
 2- expected to work, fails - obvious
 3- declared incompatible - individual test skipped; overall test run passes

We have talked about adding a --strict mode that will forbid some of
these skips.  (Indeed you could do it now with a subunit pipeline.)

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

If when you run under 2.0 you get a ugly traceback, that seems like a
bug in either the plugin or the bzr infrastructure.  You should get a
clean 'command not found'.

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

There is some stuff in the plugin guide about how to write plugins
that I think we've agreed should be moved into the core documentation.

The specification for versioning is
http://doc.bazaar.canonical.com/latest/developers/api-versioning.html

I don't think anything there is actually wrong but I do want to refine
it in the way discussed in this thread, and perhaps that document
should be expanded or made more find-able.

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