+1 /jan > On 13 Aug 2020, at 12:23, Juergen Schoenwaelder > <[email protected]> wrote: > > 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 >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
