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: +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
