On Wed, Nov 14, 2018 at 7:48 AM Robert Wilton <rwil...@cisco.com> wrote:
> Hi Martin, > On 14/11/2018 11:48, Martin Bjorklund wrote: > > Hi, > > Robert Wilton <rwil...@cisco.com> <rwil...@cisco.com> wrote: > > 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. > > So the requirement is that the versioning scheme must support > branching, and must support expressing NBC changes on any version? > > I deem that 1.4 (without the sentence about versioning by software > release) defines this: > > 1.4 The solution MUST allow for backwards-compatible > enhancements and bug fixes to be allowed in any non-latest > release. > > Although this text is ambiguous, perhaps stating it more clearly, I see > the requirement as: > > 1.4 The solution MUST allow for backwards-compatible > enhancements, and backward-compatible or non-backwards compatible > bug fixes to be allowed in non-latest releases. > > > This new 1.4 (2nd one) is much better. Thanks for rewriting it. Andy > This requirement isn't present in the current draft, AFAICT. > > (not that I support it as a requirement) > > But vendors *have* to do this today. I don't think telling our customers > that no, we can't fix that bug, because the versioning scheme doesn't allow > it is really pragmatic. > > Rob Shakir also indicated in the Netmod meeting that he does not support > this requirement. However, this conflicts with the fact that there are > examples in OpenConfig when it has been necessary to apply fixes to older > versions, which has been achieved using deviations. > > > 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. > > But, as you state in the solution draft, not even modified semver can > determine if a specific change is NBC or not. It seems you would need > the entire history to determine this - which goes against the original > idea that a client should be able to easily determine if a new version > is NBC or not, compared to the version the client knows. > > The (m|M) is intended to be a tool of last resort. So provide a mechanism > to make bug fixes to older versions, but don't encourage it. It provides a > mechanism to provide bug fixes on an existing release, but at the cost that > you lose some of the benefits of semver (which is unavoidable). > > If the server is on a version of the form "A.B.X(m)" then the client knows > that all changes between "A.B.0" and "A.B.X(m)" are backwards compatible. > If the version is "A.B.X(M)" then the client knows that there is at least > one nbc change between "A.B.0" and "A.B.X(M)". The client does not know > whether going from "A.B.X(m|M)" to "A.B+1.0" is a backwards incompatible > change or not. > > Thanks, > Rob > > > /martin > . > > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
