Re: [netmod] comments on YANG versioning

[Robert Wilton <[e-mail]>]

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.

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