Re: [netmod] comments on YANG versioning

[Robert Wilton <[e-mail]>]

On 08/11/2018 22:52, Andy Bierman wrote:
> Hi,
>
> A few comments on the netmod meeting yesterday
>
> 1) what is a bugfix?
> It is not encouraging that the DT cannot agree on the scope of a bugfix.
> But not sure it matters if NBC updates can occur for any reason.
> IMO it is easy to define a bugfix in the IETF -- it is called an Errata.
> If an Errata is approved for a YANG module in an RFC then it is a bugfix.

Ultimately we have customers that will say "this part of your YANG is 
broken" and we want you to fix it in that release train, either in the 
next release, or as a software patch.

Sometimes vendors will disagree with their customers as to whether it is 
really a bug fix or an enhancement.  Sometimes we will fix what we think 
is an obvious bug but that will unfortunately break another customer 
whom was relying on the existing behavior and then ask us to revert the fix.

I think that it should be down to the module author/owner to decide 
whether or not it is a bug fix or an enhancement, and I would just like 
a versioning scheme that allows these changes to be expressed.  None of 
this changes the fact that I think that we should be avoiding making 
these changes in the first place.  I.e. I think that there is a clear 
separation between what the versioning scheme should be able to express, 
and what is recommended practice.


>
>
> 2) SEMVER to the rescue?
> If every module release can be its own feature release train then the 
> value of
> ascending numeric identifiers is greatly diminished. The (m) and (M) tags
> do not really help.  I strongly agree with the comment that 
> cherry-picking new
> features can (and should) be done with deviations.  Updates of old
> revisions needs to be for bugfixes only.
>
> I prefer the OpenConfig "SEMVER Classic" rather than introducing a new
> incompatible complex numbering scheme to support something that
> should not be done anyway.

SEMVER classic does not support making bug fixes (even bc ones) on older 
releases.

In an older release, SEMVER classic allows:
  - editorial changes, e.g. spelling corrections or clarifications in 
description statements that do not change the API semantics in anyway.
  - bug fixes to the *implementation*, but then we are not using SEMVER 
to version the implementation anyway, only the API.

If you want to allow bug fixes (even just bc ones) in an older release 
then you either need something like modified semver, or a different 
versioning scheme that allows them.  Or you do what Rob Shakir suggests 
and use deviations for this instead, which I think is a misuse of 
deviations.

>
> 3) Bundles and compatibility modules
> I strongly agree this solution approach is far better than treating 
> every revision
> as a separate feature release train.  I don't see how I am going to
> track the major.minor.patch for 100 different modules. SEMVER is not
> very useful for telling if module A works with B, C, and D. Import by 
> SEMVER
> will probably be OK at first, but become too error-prone after awhile.

+1.  I think that the versioning solution needs to consider something 
like bundles or packages.


>
> 4) Automation tools
> Ad-hoc WEB pages from IANA do not cut it anymore.
> We need a way to get patch versions of modules published and usable
> by automation tools (without an RFC) with just the Errata report as a 
> patch.
> SEMVER requires that a module be released with the change but this is 
> not that practical.

I think that we need to have a place where all revisions of modules are 
published and easily accessible.


> Think how yocto works, using a base source version of a package + patches.
> (IMO we need YANG Packages, which would serve as recipes
> for a set of modules, features, annotations, patches and deviations, 
> that have been
> tested to work together.)
>
> 5) YANG 1.2 vs Extensions
> IMO a new YANG version would be better than extensions, especially to
> fix status-stmt, import-by-revision, deviations, and add annotation,
> patch, and many other new mechanisms to help backward compatibility.

Perhaps.  There is currently a long list of stuff on the YANG.next issue 
tracker.  My concern is that this effort will get bogged down.

Also, some of these changes we want to apply across YANG language 
versions.  E.g. I want the updated status behaviour to apply to all YANG 
modules on the server, regardless of whether of which version of YANG 
they were defined in.

Thanks,
Rob


>
>
> Andy
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod