Hi all, https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-05#section-3.3 shows how the COMPAT suffix (_compatible or _non_compatible) is "sticky" but we could use some clarifying text to explain *why* that is useful. This was raised in https://github.com/netmod-wg/yang-ver-dt/issues/84.
Here are some proposed edits in this PR: https://github.com/netmod-wg/yang-ver-dt/pull/119 It is mainly adding this paragraph: The _COMPAT modifier string is "sticky". Once a revision of a module has a modifier in the revision label, then all descendants of that revision will also have a modifier. The modifier can change from _compatible to _non_compatible in a descendant revision, but the modifier would never change from _non_compatible to _compatible or be removed. The persistency of the _non_compatible modifier ensures that comparisions of revision labels doesn't give the false impression of compatibility between two potentially non-compatible revisions. If _non_compatible was removed, for example between revisions 3.3.2_non_compatible and 3.3.3 (where 3.3.3 was simply an editorial change), then comparing revision labels of 3.3.3 back to an ancestor 3.0.0 would look like they are backwards compatible when they are not (since 3.3.2_non_compatible was in the chain of ancestors and introduced an NBC change). As well as the info in () here: iii "X.Y.Z_non_compatible" - the artifact version SHOULD be updated to "X.Y.Z+1_non_compatible" (to ensure that information about a break in compatibility is not lost). Jason
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
