[netmod] yang versioning solution complexity and alternative approaches

[Jürgen Schönwälder <[e-mail]>]

Hi,

the YANG versioning solution appears to be complex.

- We introduce version numbers that smell a bit like SemVers but then
  are not really SemVer.

- We have no solution to do meaningful things with these version
  numbers, it does not even seem to be possible to decide whether
  X.Y.Z derives from x.y.z or not. We still seem to believe that
  having compatibility constraints embedded in module imports are a
  workable solution even though we acknowledge future breaking
  changes.

- We push for a reasonably complex algorithm to calculate deltas of
  YANG module revisions to let users of modules to determine the real
  impact of module updates on their work.

I wonder why we not consider the opposite approach, namely to have
author making NBC changes to document them right where the changes
are. If authors would write something like

      leaf foo {
	nbc-change "2022-03-01" {
          description "changed type from int32 to string";
	};
	// ...
      }

then tool and humans can easily figure out in which revision NBC
changes occured and if they affect a certain usage of the module.

Instead of simply properly documenting the changes, we invent fuzzy
version numbers and complex algorithms to reverse engineer the facts
that could have easily been documented by whoever makes the change.

If the reason is that developers do not document their changes, then
go and develop tools to force them to document their changes. I do not
think it is fair to simply push the pain to the users of YANG modules.

/js

-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>