Re: [Monotone-devel] options for automate inventory

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Stephen Leake schrieb:
>>> but I really think the actual filtering should be done beforehand
>>> and not be mixed into these two methods. I know this involves a
>>> litte code duplication, but its far easier to understand later on.
>> 
>> But not to maintain; it would be too easy to change one routine
>> without changing the other.
>> 
>> If these procedure names where changed to "inventory_compute_state",
>> "inventory_compute_changes", would that make it clearer?
>> 
>> Do the comments I've added help?
>
> Which rev? Have you pushed it already?

64af48986dd641cd9da8c336b855e28b097ca6b3

I pushed it just _after_ I posted on monotone-devel. Normally I push
first; I seem to be having bad monotone karma these days.

>>> 4) A minor thing: the interface_version does not neccessarily need to be
>>> bumped to 7.1, since mtn 0.38 is 6.0 anyways... and I *think* there was
>>> a previously used rule that only command additions get a minor raise,
>>> however format / output changes of existing commands get a major raise.
>>> So either stick with 7.0 (which incorporates the attributes stuff) or
>>> raise it to 8.0.
>> 
>> The comment on interface_version in cmd_automate.cc says:
>> 
>> // Purpose: Prints version of automation interface.  Major number increments
>> //   whenever a backwards incompatible change is made; minor number 
>> increments
>> //   whenever any change is made (but is reset when major number increments).
>> 
>> This doesn't say anything about "only one increment per mtn version";
>> perhaps it should?
>> 
>> This counts as "any change", but it is backwards compatible - if you
>> don't use the options, you don't notice they got added.
>> 
>> Hmm. "don't recurse into ignored directories" is not backwards
>> compatible. But I see that as bug fix; no one should have been relying
>> on that behavior in the first place.
>
> Well, I plan to do some more incompatible changes / fixes to it anyways,
> so at least one major increment is needed for 0.39. 

Ok. As I understand the current policy, you should change
interface_version again when you make your change.

mtn 0.38 reports 6.0 for interface_version, so there has already been
a major increment in interface_version.

> The thing is that the interface_version wasn't designed to support
> "intermediate" versions of monotone at all.

Is there any rationale documentation beyond the comments in
cmd_automate.cc? monotone.info has the same statement.

If we want to have a rule that says "don't increment interface_version
minor or major number more than once for each mtn release", then it
needs to be documented in cmd_automate.cc at interface_version.

> We could define that the version numbering works that way, but I'm
> not a fan of this, because external tool developers might get
> slightly confused with that ("huh, why did the interface version
> jump two digits?")

That's what NEWS and log is for. I don't see why anyone should care
how _many_ changes have happened; they should only care if the command
they are using has changed. For that they must look in monotone.info.

> and we have also no defined way to easily query which interface
> version was set from what revision - maybe there should be a special
> tag for this purpose?

I don't see why this matters. monotone.texi identifies what
interface_version is needed for each automate command; what else is
needed?

I guess if I forget whether or not I've already incremented
interface_version for a change, I might increment it twice.

It is easy to check whether the value in the development head is
different from the value in the last release.

During development, it would work for tools to check for
interface_version > <interface_version at last release> if they want
to work with a new feature. So a policy of only incrementing
interface_version once per mtn release is workable.

Seems like we need input from a couple of other people to decide this.

>> I'm not clear; should I back out this change and just do the doc
>> update without the reformat? 
>> 
>> Or leave it as is?
>
> Well, if others are ok with it, leave it as is (I don't have to decide
> that, really ;). 

Ok, I'll leave it as is.

> Just note that, next time you do wanted/accidential formatting
> changes, do that in a separate revision to make it easier for others
> to read the diff afterwards.

Right.

-- 
-- Stephe