If module A imports from module B, then the question whether a change in module B is compatible or not for module A is answered by what module A actually uses of module B's definitions. The question is not answered by module B's version number.
The maintainer of module B can't tell whether her change breaks module A without knowing A. And the maintainer of A can't predict how module B will change in the future. As a consequence, the maintainer of A cannot realiably decide whether revision-or-derived or revision-or-derived-compatible is the right choice. The author of A has to _guess_, having more options to guess may help, or it may not. My point is that it is always a guess. The maintainer of module B may be acting in a conservative way and bumping major numbers frequently (and many times not affecting module A) or maintainer B may be lenient - and B's decision may be influenced by how central module B is, the more modules depend on B, the higher the pressure to not bump the major version number of B and to either avoid non-backwards compatible changes or to label them as compatible (even though it is possible they are not). In some realities, you end up with a need for more complex expressions over the version number space to define which versions are known to work together. And this information is often maintained _outside_ the code artifacts (one advantage being that this makes dependency updates possible without having to touch the files with the definitions). Some examples: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html https://cabal.readthedocs.io/en/latest/developing-packages.html#modules-imported-from-other-packages https://semver.npmjs.com/ Given these examples, one can ask whether decorating the YANG import statement with 'inline' versioning constraints is actually the right way to go. Perhaps dependency constraints are better managed outside. /js On Fri, Dec 11, 2020 at 07:17:22PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote: > Hi all, > > Enclosed are the materials for the Virtual Interim on Monday. Have a good > weekend! > > Rgds, > Jason > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
