I am wondering if we are looking at two sets of rules for the versioning system we come up with. One that vendors do with their "native" models to satisfy their customers, and the other what standard bodies follow for the models published by them.
For example, vendors can make feature and NBC fixes to models in releases that are not the latest, while standard bodies like IETF make changes in models that are always the latest, even as they use the same versioning system. Again, vendors use all the three numbers, but standard bodies use the first (major) and the last (patch) number. Mahesh Jethanandani mjethanand...@gmail.com > On Nov 9, 2018, at 5:52 AM, Andy Bierman <a...@yumaworks.com> 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. > > > 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. > > 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. > > 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. > 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. > > > 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
