Thanks for the comments. What you describe below is spot on and IMO is the reason why we have been going round in circles on this topic. We haven’t discussed specifying the version import constraints outside of the modules, but we should consider this approach (packages?).
Regards, Reshad. Sent from my iPhone > On Dec 12, 2020, at 8:47 AM, Juergen Schoenwaelder > <[email protected]> wrote: > > 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
