Re: [Monotone-devel] interface version / command matrix

[Thomas Moschny]

Thomas Keller wrote:
> Stephen Leake wrote:
> > With your proposal, the automate interface version is not changed
> > until just before the release, so my solution no longer works (for
> > future changes).
>
> interface_version is not designed to support such things, because it
> would make it too complex to handle them. An easy solution to your
> problem could be: "if you work with hand-compiled development versions
> of monotone, disable the version check in your application unless you
> work with a release version".

Which brings me to the question: Why don't we abandon this serial 
interface-revision number at all, and replace it with a keyword-based 
capabilities string resp. list?

This would work with a development version: together with, or directly after 
adding an automate function or a backwards compatible change, add the 
respective keyword to the list of capabilities. Each client could test on 
that keyword (capability) and instantaneously use the new function.

If a backwards-incompatible change is made, remove the old keyword and replace 
it with a new one.

It even works in case some other tool wants to provide a (subset of) mtn's 
automation interface. The subset case is (if it doesn't match that of an 
earlier version of 'original' monotone) impossible to announce with a single 
serial interface number.

There's a drawback: The list of capabilities can become quite long. And, you 
could argue, in most cases, it doesn't provide more information than you 
could get by simply trying to call an automate function, and catching the 
error returned saying that this function doesn't exist. But then, such a list 
is fetched only once, so its size probably doesn't matter.

- Thomas

signature.asc
Description: This is a digitally signed message part.