On Thu, Aug 27, 2020 at 05:21:13PM +0000, Joe Clarke (jclarke) wrote:
>
> If I make a non-backwards compatible change to the definition of
> object-identifier in ietf-yang-types, then likely >98% of the modules
> importing ietf-yang-types will not at all be affected by this. Still I
> would have to declare a major version change triggering a lot of 'uhm,
> ehm, what'. Expressing incompatibilities at the module level is pretty
> arbitrary since the way definitions are organized into modules is
> already somewhat arbitrary.
>
> I feel the hint is still helpful, especially for those that may be in the <2%
> group, whereas not causing an undue burden given that without it, that >98%
> group would have to take every module change and analyze them for relevant
> changes.
>
If you mark the definitions that changed, tools can do the work to
figure out whether importing modules are affected or not. This is
relatively straight forward for a compiler that already knows what is
used and what is not used, this does not require much magic.
Instead, the approch taken here is to provide a somewhat vague warning
indicator (the version number) at the module level and then you rely
on tools (or humans) to identify semantic changes. And tools will
likely fail if semantics in descriptions have changed or they will
fail to decide whether two regular expressions are backwards
compatible or not or if a must statement is equivalent to a previous
when statement in a certain context. For the person making the change,
however, it is fairly easy to leave a mark since he/she can be
expected to understand the nature of the change.
It turns out that we already have some marks in the form of the status
statement. We can mark definitions as deprecated or obsolete. We do
not have a value to say 'changed' in an nbc way and we do not have a
mechanism to document the history of status changes for a given
definition, but that is easy to engineer into YANG.
/js
PS: I assume that we focus on 'published' YANG modules where the nbc
change churn is reasonably under control. During active
development phases, modules may undergo many little (nbc) changes
but dealing with them should be left to version management
systems.
--
Juergen Schoenwaelder 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
