Bazaar spontaneously unusable

[Martin Pool]

On 9 April 2010 15:08, Aaron Bentley <aaron at aaronbentley.com> wrote:
> On 04/08/2010 07:39 PM, Aaron Bentley wrote:
>>
>> 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.
>
> And now, I have discovered that bzr.dev is incompatible with my 2.2, because
> the position of BranchReferenceFormat.initialize's target_branch parameter
> was changed.  (The api minimum version was not changed, AFAICT.)

The api minimum version at that time was 2.2.0 and it still should be:
we don't distinguish API changes within a beta series, which would be
what you would have needed here.

I agree with you that:

> I still don't feel comfortable saying something is compatible until I've tested it.

therefore I think anything based on a manually-updated API version is
a lost cause.  Any particular plugin only relies on a fraction of the
whole api and if the api version counts very fast it will always trip.
 And on the other hand sometimes the API version will not increment
when it should, either because we simply forget to (which may be
fixable) or because we can't predict what behaviour a plugin will
depend upon.

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

That could also work.  We could easily do both, with the typical list
of allow/deny patterns.  Then I think we can get away from the whole
API version issue, and just be making statements of fact about "this
combination does work" or "this combination doesn't work" rather than
trying to predict it.

If there are cases where we're breaking compatibility for no good
reason I'd like to see if we can avoid it.  If there are failures in
Launchpad testing then at least knowing what general kind of thing
goes wrong would help.  We do get some kind of sense of what breaks
qbzr or others now.

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

Right.

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