detecting version match/mismatch between core/plugins

[Martin Pool]

On 10 Aug 2006, "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.

It's a very good point.

At the simplest level plugins can check the bzrlib version and perhaps
should give a warning if they're out of date.  They can do this now.
That would handle the main use cases you mention.

I tend to get trouble sometimes from plugins which work with the last
release but not with bzr.dev, or vice versa.  We could add a way to look
them up from particular directories, but it's not likely to affect many
end users.  (In fact you can probably do it now by installing them onto
somewhere on your PYTHONPATH; putting them under the bzrlib/plugins
directory of the version being run might do it.)

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

Do you mean the plugin code should contain a branch location?  Maybe it
should.  If we standardize tags in 0.10, which I intend/hope to do, then
we could just look for a tag there corresponding to the current bzr
version to work out which one to pull.

-- 
Martin