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

[Thomas Keller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Leake schrieb:
>> 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.

Thanks, I fixed that. *grumbles at MoinMoin*

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

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.

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

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.

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

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

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

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

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

> 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" ;)

Thomas.

- --
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFH7LUCaf7NlBYNEJIRAoDaAKD4c26EyERnCa/UBTe0pwyIveV4QgCfdY/y
q7EOT5N3x3T0Wcx3egsUo5c=
=PBYP
-----END PGP SIGNATURE-----