Subject: [yang-tooling] Re: file name conventions for sid-file-version
From: Andy Bierman <[email-masked]>
To: Carsten Bormann <[email-masked]>
Cc: Michael Richardson <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sat, 7 Feb 2026 11:07:48 -0800
List-Id: "Contributing to and tracking the progress of YANG tooling, as it concerns IETF work that uses YANG." <yang-tooling.ietf.org>

.....

> In the real world YANG modules are not nearly as global as the IETF
> imagines.
>

Actually the IETF is aware now, and the YANG Semver work deals with
multiple release trains
and non-backward compatible changes.

But adding nodes to a grouping is a normal BC change.
Maybe there should be YANG guideline not to do this for exported groupings,
but that does not really solve anything.

I think the megarange tool needs to generate the new SID file with the
current module set
even if the revision is the same as the last SID file.
Any differences and the sid-file-version needs to increment.

A simple hack I thought of -- have the tooling generate warnings to update
the revision date
on the 'top' module (or even generate the new YANG file).
Avoid the use of sid-file-version whenever possible.

It is more than confusing that the contents of foo@some-date depend on the
date you compile it, not the
revision date.  It is critical for SID files.

The same (modname, revision-date) does not always resolve to the same
> contents.
> These systems rely on <get-schema> or copying and altering the YANG
> modules as needed.
>
>
> Grüße, Carsten
>>
>>
> Andy
>
>

Andy