For me, this all looks absolutely backwards. Humans make changes and it can be expected that humans document changes that violate the YANG backwards compatibility rules. Hence, I prefer:
Any change that is not backwards compatible acording to the YANG update rules MUST be tagged. This is a simple and well defined rule. The rules that were proposed are instead defined using some hypothetical machine and vague terms such as easy, realistic, complex or unrealistic. Such terms escape my understanding of sound engineering since they all are subjective and not well defined. Furthermore, either there is a defined algorithm (machine) or there is none. And furthermore, assuming that everyone has access to an implementation of such an algorithm is another interesting idea. Why is it too much to ask people breaking backwards compatibility to properly document where they do so? /js On Tue, May 24, 2022 at 02:09:10PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote: > YANG Versioning Weekly Call Minutes - 2022-05-24 > > As part of "per-element" BC/NBC tags, we need to define default assumptions > that a tool will make for certain types of module changes. Note that these > are just assumptions, not definitive rules that these changes are indeed NBC > or BC. In some cases, there will be a default assumption below, but an author > is obligated to document whether a change is BC or NBC (e.g. for a "must" > statement the tool will assume NBC, but the author will decide if it is > really BC or NBC, and potentially tag that element, based on whether the > constraint is relaxes or not, as per RFC 7950). > > A) descriptive strings (e.g. description, org, presence argument string, > revision, units): editorial (for add/remove/change) > > B) changes that a machine should be able to compare and easily determine BC > vs NBC (e.g. YANG version, range, import, adding a "must", etc): as per > rules in draft > > C) changes that are complex/unrealistic for a machine to figure out (e.g. > changes to patterns, must statements, when statements, and leafref paths): NBC > > D) extensions: if it is a known extension to the tool then use the defined > rules for that extensino. If unknown, then assume BC but flag "unknown > extension additions / removals / changes". Note: > - some models are sprinkled with BC extensions > - some models are sprinkled with NBC extensions > > Balazs: New github issue: codify how extension additions/removals/changes are > BC vs NBC in a machine readable way > [ maybe in tool comparison draft ?] > > Jason: New github issue: did we forget to say that import changes are BC in > module versioning ? (adding, removing, changing the import by revision, > etc). Add to section 3.1.1. > > We're now done going through the feedback on WGLC from Jurgen, Italo and > Andy. Responses are in progress by Reshad, Rob and Joe. > > Next meeting: talk about Comparison Draft and Packages > > ---------------------------------------------- > Versioning work on Github: > https://github.com/netmod-wg/yang-ver-dt > > ---------------------------------------------- > Weekly webex call details: > > Meeting number (access code): 161 096 5630 > Meeting password: semver? > > Occurs every Tuesday effective Tuesday, November 16, 2021 from 9:00 AM to > 10:00 AM, (UTC-05:00) Eastern Time (US & Canada) > 9:00 AM | (UTC-05:00) Eastern Time (US & Canada) | 1 hr > > https://ietf.webex.com/ietf/j.php?MTID=me2c6491ebcc37b8127c1244d244d2754 > Tap to join from a mobile device (attendees only) > +1-650-479-3208,,1610965630## Call-in toll number (US/Canada) > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
