On Wed, Aug 26, 2020 at 05:43:27PM +0000, Joe Clarke (jclarke) wrote: > > > > 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. >
The goal of the effort was to allow for non-backwards compatible changes. Backwards compatible changes already work today (and white space changes are obviously backwards compatible). If you want to _publish_ a module with just whitespace changes, it is defined how to do this. I would find it way more important to mark which specific definitions had backwards incompatible changes (plus perhaps hints how to deal with them) instead of sticking a label on an entire module and then to let others figure out what this label actually means for them (and ultimately it is then the package maintainer's job to dig out which revision sets can meaningfully work together). If I make a non-backwards compatible change to the definition of object-identifier in ietf-yang-types, then likely >98% of the modules importing ietf-yang-types will not at all be affected by this. Still I would have to declare a major version change triggering a lot of 'uhm, ehm, what'. Expressing incompatibilities at the module level is pretty arbitrary since the way definitions are organized into modules is already somewhat arbitrary. /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
