Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Aug 26, 2020 at 05:43:27PM +0000, Joe Clarke (jclarke) wrote:
> 
> 
> > On Aug 13, 2020, at 06:23, Juergen Schoenwaelder <[e-mail]> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>