detecting version match/mismatch between core/plugins

[Michael Ellerman]

On 8/11/06, Wichmann, Mats D <mats.d.wichmann at intel.com> wrote:
>
> Pardon a newbie question, since I don't know
> much of what's in the plans, or even that much
> of what's actually implemented.
>
> Plugins seem to be an imporant part of the design.
> I'm wondering if there's a way that we can detect
> if versions go out of skew.  I already stumbled
> across a simple instance, when I followed the
> wrong link on the plugin registry page and got
> the devel version of bzrtools instead of the one
> matching bzr 0.8.2 - simple operator error but
> the resulting error was, er, arcane.
>
> I guess there are three operations I can think of
> off the top of my head that would interest me in
> this space:
>
> - ask if there are newer versions of my plugins
> (assuming I will only be told about ones that
> are compatible with my bzr core version)
>
> - after upgrade of core, inform me of plugins
> that need to be updated for compatibility with
> the new core
>
> "bzr check-plugins" maybe for those two?
>
> - if I invoke an incompatible plugin that I
> managed to pull somehow (see above, or else,
> after a core upgrade rendered one incompatible),
> get a somewhat useful error about the version
> mismatch
>
> To me this seems like maybe it should be part
> of the plugin "API" such that each plugin could
> be queried for what it knows wrt. the core
> version; and for what it can't know (things in
> the future like a new version available) maybe
> consult a built-in url.

Currently there's no versioning of plugins at all, some plugins take
care to try and be backward/forward compatible, but others don't and
generally only work with the latest bzr.

It would be easy enough to have a version number in the plugin and
fail to load it if it's too low or high, it would just require someone
to write the code :)

cheers