Re: [netmod] comments on YANG versioning

[Andy Bierman <[e-mail]>]

On Wed, Nov 14, 2018 at 7:48 AM Robert Wilton <[e-mail]> wrote:

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