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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
