Re: [netmod] comments on YANG versioning

[Martin Bjorklund <[e-mail]>]

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?

This requirement isn't present in the current draft, AFAICT.

(not that I support it as a requirement)


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


/martin