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. > 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. > 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? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod