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

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Hi!
>
> I just started on
>
> http://venge.net/mtn-wiki/AutomateVersions

One nit; the link at the bottom, to "monotone's Automation documentation"
http://monotone.ca/docs/Automation.html%22#Aut%22omation 
is broken.

> As you can see in the matrix it was quite common that we went away
> from our minor/major increment rules in the past because nobody or
> everybody felt responsible to change interface_version in
> cmd_automate.cc, practically leading to a mess for the next release.

Yes, that explains the lack of C's.

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.

> Now, a simple new rule could be: Whenever you touch an existing
> automate command, also mark it as changed ("C") on this wiki page for
> the next upcoming interface version (which would then either be 7.1 or
> 8.0). The release coordinator then looks at the page and if he only
> encounters "A"'s in a col, he'd do a minor increment, however if he
> encounters at least one "C" in the column, he'd do a major
> increment.

That makes sense, with the addition of "B" for backward-compatible
change from your next email.

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.

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

In practice, you can just check the mtn version, since the automate
interface version changes in sync with that.

Emacs DVC has code that checks the automate interface version (to
determine whether inventory supports --no-ignore), but that is mostly
to support my hacking; it could just check the mtn release version.

Hmm. The reason I added that check was to distinguish between the
released 0.38 (without --no-ignore) and the development 0.39 (with
--no-ignore). The problem was that the development code still reported
its version as 0.38, so I needed another way to distinguish them; I
changed the automate interface version.

With your proposal, the automate interface version is not changed
until just before the release, so my solution no longer works (for
future changes).

A more radical suggestion would be to simply delete the automate
interface version, and just record the mtn version for each automate
command. 

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.

-- 
-- Stephe