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