Re: [netmod] comments on YANG versioning

[Martin Bjorklund <[e-mail]>]

Robert Wilton <[e-mail]> wrote:
> Hi Martin,
> 
> On 14/11/2018 11:48, Martin Bjorklund wrote:
> > Hi,
> >
> > Robert Wilton <[e-mail]> 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 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.

The pragmatic thing to do is to violate the rule when you think your
customers can accept it, and introduce a NBC even though it doesn't
follow 7950 section 11 rules.

> 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).

Suppose I have version 1.2.3M.  Now I make an editorial fix to this
module, what is the next version?  1.2.4 or 1.2.4M?


/martin




> 
> 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
> > .
> >