On Mon, Dec 14, 2020 at 9:17 AM Sterne, Jason (Nokia - CA/Ottawa) < [email protected]> wrote:
> Hi Andy, > > > > I like the way you phrased it "too fragile to be useful". > > It seems intuitively obvious that determining compatibility with versions that may exist in the future is mostly speculation. Also obvious: there is little benefit writing automation code to determine "X will work" if you still have to write the code to implement X and check for errors. Might as well just try X and determine if it did or did not work. > > 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). > A common use case is for shared data types like ietf-yang-types. If the module uses "hex-string" then the RFC 6991 version must be found or else the RFC 6021 version can be used. I support the extensions for the import-stmt that help the compiler find the right version. Although not a good practice, in this case the "import-without-revision" semantics are not changed if an extension is used to restrict the search for the import. > > > Jason > Andy > > > *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]> 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] > > 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
