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

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Stephen Leake schrieb:

>> Which means we probably should use two digits for the minor number;
>> we'll probably have more than 10 backward-compatible changes before
>> the next incompatible change.
>
> Ok, this is another thing which should be ruled: in my opinion what
> follows on x.9 is x.10 aso. In guitone I split up on "." and compare the
> major and the minor numbers separately.

Well, that works, but it's clearer if we go from x.09 to x.10. 

>> Another nit: you have a C for inventory for 7.0. That change was the
>> addition of --no-ignored, --no-unknown, --no-unchanged,
>> --no-corresponding-renames. That was backward-compatible, so it should
>> be B.
>
> This is, like the --depth thing, debateable. I fully agree that the new
> options are backwards-compatible, however, the change that it no longer
> recurses into ignored directories which happened in the same release was
> for me backwards-incompatible, because for a given fixed input the
> output, i.e. the amount of nodes returned, changed significantly.

Ok. I just viewed that as fixing a bug. Not a big deal.

>>> I'm still undecided if / how we can handle "collateral" changes, like
>>> f.e. Derek's recent change wrt --depth option  handling. This - 
>>> theoretically - alters the output for at least two automate commands
>>> (inventory and get_current_revision), which might expect a definite
>>> output for a certain input.
>> 
>> I don't think that should change the automate interface version. 
>> 
>> In general, an external tool will have to check both the mtn version
>> and the automate interface version; there are other things that are
>> outside the automate interface that an external tool relies on as
>> well. The --depth change is indicated by the mtn version.
>
> Well, the question is why an external tool should rely on two version
> strings where one could already be enough... 

Yes! The monotone version is enough.

> Also, for certain upcoming functionalities this is impractical.
> Thomas Moschny works on a python-based restful HTTP/JSON interface
> to automate. If a client connects to such a server, how can it ever
> find out the monotone version string? 

mtn automate version

would do it.

> All it can do is query the interface version, and this is there for
> exactly this reason. And I certainly don't like to introduce
> `automate monotone_version` - at least not for this purpose.

If the interface version did not exist, then this would return the
monotone version number; all we need.

>> In practice, you can just check the mtn version, since the automate
>> interface version changes in sync with that.
>
> Not always. In the past there have been quite a few releases where
> nothing had been changed, so interface_version kept constant. This is
> also wanted; if you develop a tool that relies on a certain interface
> version like 8.3, you should be able to safely deploy that with any
> monotone release with an interface version 8.3 <= x < 9.0. 

Hmm. I guess you are implying that this tool should complain that it
might not work on a version that is 9.0 or greater. Ok, that makes
sense. But it is quite likely overconservative. For example, how many
tools actually _relied_ on inventory recursing into ignored
directories? 

But you have ignored my point that it is just as likely that a tool
that works on mtn 0.38 might not work on mtn version 0.40.

Unless the tool uses _only_ automate commands, it _must_ check the mtn
version number. I don't think automate is powerful enough for that.
Nor do I think it needs to be.

> No code changes would need to be done on the client's side to
> support a new monotone release which does no or just a minor changes
> to the interface.

I define "the interface" to include the mtn commands, as well as the
mtn automate commands.

>> A more radical suggestion would be to simply delete the automate
>> interface version, and just record the mtn version for each automate
>> command. 
>
> This would be possible, of course, but again, the interface developer
> would need to change his code on practically every monotone
> release...

I don't see why. Only when there are incompatible changes that
actually affect the tool.

I guess you are saying that you expect tools to rely _only_ on the
automate interface. Do we have examples of such tools? Emacs DVC
relies heavily on the non-automate commands.

Although it may be that there are ways to effect some of the
non-automate commands via automate. You have mentioned that your tool
does not use 'mtn commit', but rather some combination of automate
commands. It would be useful to document that combination in the mtn
user guide.

>> Then, to distinguish development from release versions, increment the
>> mtn version immediately _after_ a release, instead of immediately
>> _before_. That's what Emacs does; the release is version 22, the
>> development is version 23.
>> 
>> That would be useful for the changes outside the automate interface,
>> as well.
>
> I guess this is another reasonable option for your problem and I'd
> support that as well "on the outside" ;)

Ok. I'll suggest it again immediately after the 0.40 release.

-- 
-- Stephe