Bazaar spontaneously unusable

[Andrew Bennetts]

Aaron Bentley wrote:
[...]
> 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.

Agreed.

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

One issue is that I believe the packaging can easily be out of sync with
the plugin's internal API checks.  So if the Depends field of the deb
packages reliably stated exactly what the plugin checked at runtime,
that would be nice (and similiarly for other package/bundle formats).  I
guess this suggests that the version number checks should be more
machine readable than just some code in the __init__.py, so that
automated tools can easily extract it and compare it with the packaging
metadata (or use it to construct that metadata).

It would also make it easier for someone to write a tool that finds all
the projects in the “bazaar” project group on Launchpad (or just uses a
hard-coded list of plugins), grabs their latest tarball release (and
maybe also trunk?), looks at the machine-readable “I require bzrlib
x.y.z” declarations, and spits out a report saying which plugins need
updating (or have been updated but need to make a release with the
update).  Then as a bzr releases draw near someone (the RM, a plugin
liason, the community in general?) can run the report and remind the
relevant plugin maintainers to update their plugins.

-Andrew.