Re: [netmod] Materials for NETMOD Virtual Interim meeting (Monday)

["Sterne, Jason (Nokia - CA/Ottawa)" <[e-mail]>]

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 <[e-mail]>
Sent: Saturday, December 12, 2020 10:39 AM
To: Juergen Schoenwaelder <[e-mail]>; Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>; [e-mail]
Subject: Re: [netmod] Materials for NETMOD Virtual Interim meeting (Monday)



On Sat, Dec 12, 2020 at 5:47 AM Juergen Schoenwaelder <[e-mail]<mailto:[e-mail]>> 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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netmod


--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netmod