> On Aug 13, 2020, at 06: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?
Sorry for the delay. I was traveling and then trying to get caught back up. Yes, things got off track a bit here. > > - 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. Agreed. And through that development, we are not trying to impose any versioning up to the point that a module would be published (e.g., in a draft where it might be implemented). Certainly, people could also pull and implement any arbitrary revision from a VCS, but we haven’t created any text to cover that (nor do I think we want to impose that each commit revs some version in the module itself). > > - 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. The intent, at least for the whitespace changes was at a module release time to indicate what constitutes a version bump. But the question could likely be rephrased. Would one change the _revision_ of a module for any of the changes mentioned thus far? And if a new revision is created, and semantic versioning is used a revision-label scheme, then that revision should have a new version label. At least this was the opinion of the contributors in the regular weekly calls. Joe _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
