Hi Andy, I like the way you phrased it "too fragile to be useful".
I think that's a concern we'd also have with an "or-compatible" version of import by revision-or-derived. Authors may use it "to be safe" (similar to how they may want to specify an exact vesion) but it would end up keeping everything to tightly in lock step. With just the "revision-or-derived" we would solve the MINIMUM VERSION problem, but then leave all the other complexities of compatible versions outside the scope of import statements. (e.g. solve that with information outside the modules themselves like Packages). Jason From: Andy Bierman <[email protected]> Sent: Saturday, December 12, 2020 10:39 AM To: Juergen Schoenwaelder <[email protected]>; Sterne, Jason (Nokia - CA/Ottawa) <[email protected]>; [email protected] Subject: Re: [netmod] Materials for NETMOD Virtual Interim meeting (Monday) On Sat, Dec 12, 2020 at 5:47 AM Juergen Schoenwaelder <[email protected]<mailto:[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. It seems that SEMVER is a choice between a version that is not granular enough to be useful, and a version that is granular enough, but now there are so many versioned items that the system is unmanageable. Taken to its logical extreme, every construct would need a semver and every import would need to be at the granularity of 1 identifier. The owner of module A can only update/fix the import of B after the owner of B has finished breaking backward compatibility (or not). This only invalidates the utility of the upper bound of semver, e.g., the newest version of B that can be imported by A. The fatal flaw in YANG imports has always been that import EXACT version is too fragile to be useful. When module A is written, the author knows the MINIMUM VERSION of B that can be imported, yet YANG has no way to express that. For BC changes (which are the vast majority) this is sufficient. Please just fix that. Andy 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]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
