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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
