On Thu, Aug 13, 2020 at 11:37:18AM +0200, Ladislav Lhotka wrote: > > > $ pyang -f yin ietf-inet-types.yang | xmllint --c14n - | sha256sum > 8d1ca8f30566ce8cbeffa095e20642f8f6e9f3a724286be4ead863b4467dc40b - > > might be a very good start. It is certainly much more robust than > relying on a simple checksum of the YANG module text.
This work started with the need for _semantic_ version numbers and now we are down to hashes of modules? Do we still have a clear idea which problem we are solving? - Sane development environments use version control systems, we should in my view not attempt to go there. We should assume that people developing YANG modules use version control systems to track changes. - There apparently is a need for a packaging system that can express which combinations of YANG module version are known to work together. The YANG versioning work was driven (I think) by the desire to support non-backwards compatible changes (section 4 of draft-ietf-netmod-yang-versioning-reqs-03). Why do we end up discussing how to calculate hashes or the impact of whitespace changes? Whitespace and layout changes are backwards compatible, even today's YANG versioning rules handle them well. /js -- 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
