Hi Michael,

I don't have the statistics to hand, but there are multiple vendors who wanted 
this functionality and at the end of the day if a customer is paying for 
support then they expect to be supported and bugs fixed.

Today, I suspect that the "solution" is to just ship the fix and increment the 
patch version number, ignoring the Semver rules, which hides the NBC changes 
and would still potentially break clients, and Semver clearly starts to lose 
its value if you don't actually follow semantic versioning.

There are other hacks that can also be used to mitigate this (deviations, 
adding extra YANG modules, etc, but they add more complexity and don't work in 
all cases).  The industry wanted to use semantic versioning numbers, but Semver 
doesn't natively support any sort of branched history.  The vanilla Semver 
approach assumes that you have a single linear branch and are updating the head 
of the branch, or at least this is my interpretation and understanding.

Kind regards,
Rob



From: Michael Richardson <[email protected]>
Date: Thursday, 4 June 2026 at 17:15
To: Rob Wilton (rwilton) <[email protected]>; [email protected] <[email protected]>
Subject: Re: [netmod] Re: Mike Bishop's Discuss on 
draft-ietf-netmod-yang-semver-26: (with DISCUSS and COMMENT)

--------

Rob Wilton \(rwilton\) <[email protected]> wrote:
    > Instead, the limited branching is designed to allow the owner/publisher
    > of a YANG module to patch a fix to an older version of that YANG module
    > after they have already published a new version so that users of that
    > old module version are not forced to update to the latest version.

How often does this happen?
It seems like some kind of vendor/implementor mistake.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email protected]  http://www.sandelman.ca/        |   ruby on rails    [
]       My working hours and your working hours may be different.            [
]  Please do not feel obligated to reply outside your normal working hours   [

_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to