On Sat, Nov 02, 2024 at 12:03:43PM +0000, Joe Clarke (jclarke) wrote: > Thanks for the feedback, Jürgen. Being the editor on YANG Semver, let me > respond to some of you points there. > > > * YANG Semantic Versioning > <draft-ietf-netmod-yang-semver-17> > > - The claims made in the first paragraph of the abstract about the > versioning document do not seem to be aligned with that document > when it says "a more flexible approach to importing modules by > revision". My understanding is that the versioning document says > that collections of suitable modules are maintained outside of > YANG modules and there is a recommended-min-date, which is a piece > of documentation but not changing YANG's current import logic. > > [JMC] The YANG Semver abstract _itself_ defines the rules for import by YANG > Semantic Version. Those rules are defined in the YANG Semver draft Section > 5. That said, the module versioning draft _does_ define import guidelines > based on recommended-min-date (see section 4.1 of that document).
I now see that it is the first paragraph in the Introduction not the first paragraph of the Abstract. Anyway, if this document updates YANG import rules, then spell this out and point to where the change is made. The versioning document does not seem to change YANG import rules. > - I am still confused by the complexity introduced here. Why do we > need both X.Y.Z and X.Y.Z_compatible? What is the difference, when > do I use which? > > [JMC] In the overwhelming majority of cases you would use X.Y.Z. In fact, I > believe in all IETF cases, only X.Y.Z would be used. It’s best to describe > the “why” of the _compatible modifier with specific numbers. Let’s say you > have a module versioned 1.2.3 and you want to add a feature (i.e., make an > otherwise MINOR change). However, module 1.3.0 has already been published. > In this case, you would publish a 1.2.4_compatible. This might be a very > real case with vendor modules. I read this as "you should bump the minor number but since it is already taken, you add _compatible". So _compatible always affects the interpretation of the minor version number? If _compatible means treat X.Y.Z_compatible as X.Y+1.Z even if X.Y+1.Z has been published, then perhaps say so more clearly? It was not clear to me that _compatible means "we should have bumped the minor version number but did not do so", well, perhaps this follows from the text. > - X.Y.Z_non_compatible sounds like a somewhat questionable idea. To > me, this says "we claim this is X.Y.Z but we know it should be > something different". The _non_compatible modifier essentially > overwrites the meaning of [SemVer], rendering X.Y.Z at best into a > branch identifier. Perhaps this is what the industry really wants, > three digit branch identifiers but not really [SemVer]? > > [JMC] The intent of this is to signal to a consumer that, say, > 1.2.5_non_compatible is based on the 1.2.4 version of the module but changes > have been made that would render it not backwards compatible with 1.2.4 and > one should be aware of that. We think this will be lightly used, but it has > been seen in the wild, especially with vendor modules. > > > - The example in Section 4.4.1 is interesting and welcome but > unfortunately there is no recommendation how situations should be > handled if branches split off (and perhaps even merge later). > > [JMC] I think we can add some text here to anchor to the fact that within a > MAJOR branch (without the _non_compatible modifier) backwards compatibility > can be preserved when branches diverge and are later merged. I think this > will be left to developers how exactly this is handled. In one case you > might choose to incorporate all changes so that HEAD reflects an aggregate of > changes (a true merge). In other cases it might make sense to leave the > branches divergent and have a new MAJOR branch. > > > - If I need to make a BC update to X.Y.Z_compatible but > X.Y.Z+1_non_compatible has already been taken, what do I do? > > [JMC] The _non_compatible modifier takes precedence. So you could do > X.Y.Z+2_non_compatible. This is one reason why we say that this scheme > supports limited branching. > > - I am not sure how the recommended-min-version helps if there are > branches since there is not guarantee that 2.0.0 > v1.1.1 implies > that 2.0.0 includes everything that was in 1.1.1. If > recommended-min-version is 1.1.1, then an import of 2.0.0 may > still fail, no? > > [JMC] Yes, it could. But it is not true that 2.0.0 necessarily implies that > it includes everything in 1.1.1. The MAJOR version change means that there > are non-backwards-compatible changes and you will need to look at this 2.0.0 > to see how it affects your tooling. > Given the discussion above: Given a recommended-min-version of 1.3.0, a 1.2.2_compatible module may actually work. And there is no guarantee that 2.0.0 will actually work. (Sure, any claims about future versions are difficult once we allow NBC changes.) So even claims about lower version numbers may not necessarily always be correct. It seems there is no well defined partial order with _compatible and back ports may cause a recommended-min-version declaration to be inaccurate. > - An existing compliant YANG compiler will not "locate a module with > a version that is viable according to the conditions above". An > existing compiler YANG compiler will ignore the extension > statements recommended-min-version (and recommended-min-date). I > think you need to acknowledge this and word things differently. > Sure, a compiler that supporting recommended-min-version may > generate suitable warnings, but existing compliant YANG 1.1 and > YANG 1 compilers can't be expected to do something fancy due to > the presence of an (from the compiler's perspective) unknown > extension. > > [JMC] Thanks. Where in the doc are you looking? > > I don’t find the exact text you quote. Section 5.2 comes close, but it’s > not exact. This text: If an import by recommended-min-version cannot locate a module with a version that is viable according to the conditions above, the YANG compiler should emit a warning, and then continue to resolve the import based on established [RFC7950] rules. > [JMC] But a compiler that is compliant with (or aware of) YANG Semver, would > be able to emit a proper warning if it cannot locate a module that meets the > import rules. I agree that a standard YANG 1[.1] compiler would not be aware > of this extension and would therefore load an available module by name and > might ultimately end up with compiler errors. My struggle has always been about the situation where two YANG 1.1 compiler, given the same set of YANG modules, resolve imports differently and thus they work with semantically different data models. It seems you are still planning to split the world into 'YANG 1.1' compilers and 'YANG 1.1 semver' compilers. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
