Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00

[Robert Wilton <[e-mail]>]

On 26/07/2018 15:16, Juergen Schoenwaelder wrote:
> On Thu, Jul 26, 2018 at 11:19:07AM +0100, Robert Wilton wrote:
>> I think that some aspects of versioning are the same problem.  E.g. I think
>> that there is a difference between a major release where more backwards
>> compatible changes could be expected, vs maintenance releases where one
>> would expect backwards compatibility should likely be preserved.
>>
> Well 'could be expected' and 'would expect backwards compatibility
> should likely be preserved' is kind of hand-waving. There are often
> situations where people are reluctant to bump major version numbers
> just because a tiny bit of an API has changed in a non-backwards
> compatible way - for the same reason that you brought up. Most of the
> definitions did not change, so people do not want to bump the major
> version.
Yes, exactly.

I think that there will always be a reluctance to change the model name 
(e.g. to "module-v2") unless it can truly be made low impact to clients, 
importing modules, etc.  And if we get to something that is low impact, 
then it may well be that we end up with something that is logically 
equivalent to semver anyway.

There may be less reluctance to bump the semver major version number - 
although I agree with you that non backwards compatible bugfixes may be 
a grey area.

E.g. one common non backwards compatible change that I see recently 
between Native YANG models was changing from int32 to uint32 for list 
indexes (mostly in config false nodes).  I don't have the history as to 
why the change was made, but for all intents and purposes the effective 
value set is the same (but not specified in the model), but the encoding 
could differ, and hence it is regarded as a non backwards compatible 
change.  As an aside, part of me wonders whether classifying this as a 
non backwards compatible change is right, although I can see why it is 
specified that way.




>
>> This was similar to a comment above.  I don't like the (module, path) of a
>> data node having to change (due to a module name change for a major version)
>> if its definition hasn't changed at all.
> Fine. Then you deprecate the broken foo and create foo'. You do not
> like that because you do not want foo and foo' at the same time. But
> others want deprecated objects to stay to allow a transition period.
Basically yes.

I also think that perhaps there is a level of pragmatism here:
  - if a particular node is widely used, but needs to be changed, then I 
think that we are far more likely to create foo', and continue to 
support foo.
  - but if the node (or nodes) were effectively broken for some reason, 
then even if it is being used by some customers, I think that there is a 
preference to just fix in place.

I think that it just goes back to stability.  The models start off 
somewhat unstable, and then gain stability over time.  We want to be to 
modify/fix them when they are new, but once there are older, we would 
expect a much greater level of stability in them.

>
>> Yes, both of these are right.  And partly it is a chicken and egg problem.
>> We would like clients to migrate from CLI to YANG, but that requires stable
>> models, but don't want to invest heavily in creating stable models in YANG
>> if customers are not using it. Having two separate sets of standard models
>> (e.g. IETF and OpenConfig) doesn't help either.
> So do we hit a requirement (which is independent of versioning) that a
> mechanism is needed to select different module sets (or views), given
> that the reality gives us overlapping and competing models? And then
> as a side effect, such a mechanism may also be used to select between
> different versions?
Yes.

Thanks,
Rob

>
> /js
>