Re: [netmod] Deviations and augmentations

[Robert Wilton <[e-mail]>]

On 13/11/2018 17:06, Juergen Schoenwaelder wrote:
> On Tue, Nov 13, 2018 at 03:54:11PM +0000, Robert Wilton wrote:
>
>> Today, just using the status element alone to mark removed nodes means that
>> a client would have to check for all changes in the module between two
>> revisions to determine whether or not the new module revision is backwards
>> compatible with the old one.
> A client needs to know whether it is _affected_ by changes. This
> requires to match what is used by a client against what has been
> changed (including any changed deviations). A three digit number
> simply does not tell you that.
>
> <soap>
> Corner cases:
>
> - An implementation claims to support the latest semver but then
>    deviates things back to an earlier version.
>
> - An implementation claims to support an earlier semver but then
>    deviates things forward to a more recent version.
>
> Of course, nobody would do that...
> </soap>
>
> My point is that semver is _at best_ a hint whether there is a version
> mismatch potentially affecting a client. It is not sufficient to
> determine whether there is indeed a problem.
>
> In other words, robust automation requires to match what is used by a
> client against what has been updated (taking deviations into account
> during the comparison).

I don't disagree with any of this, I'm also a proponent of a schema 
comparison tool.

I think that my main point regarding version numbers is:

  - If we are going to use semver then we should define and follow the 
rules strictly.  I.e. assuming that the semver has been populated 
correctly then it should be possible to determine whether the change is 
a nbc, bc, or editorial change.  I think that a solution where semver is 
done in a half-hearted way is entirely useless (e.g. if clients cannot 
trust the version number).  I think that there is a pretty clear 
requirement to support NBC changes to older revisions (i.e. I really 
mean bug fixes but a looser interpretation than your definition), and 
hence I don't think that vanilla semver is sufficient.

- An alternative is to not use a semver version number at all, instead 
we define a non semantic 3 digit version number that is something like:

  major = significant changes to the module have been made
  minor = smaller changes/feature enhancements to the module have been made
  patch = a bug fix to the module has been made.

Clients, module readers, etc, and then required to use a schema 
comparison tool to determine what the actual changes between two 
revisions are and whether or not they will be broken by those changes.

Thanks,
Rob


>
> /js
>