On Sat, Dec 12, 2020 at 5:47 AM Juergen Schoenwaelder < j.schoenwael...@jacobs-university.de> 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 > > netmod@ietf.org > > 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 > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
