Robert Wilton <[email protected]> wrote: > Hi Martin, > > On 14/11/2018 11:48, Martin Bjorklund wrote: > > Hi, > > > > Robert Wilton <[email protected]> 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 > > . > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
