MIME-Version: 1.0
References: 
 <CABCOCHR+XGn-fbMPJ=p1KtJ=GftBC-Jxz4eDm5Os3ZZ2J_5GdQ@mail.gmail.com>
 <1517396.1770457190@dyas>
 <CABCOCHR-gVQ3s89FZL8hfOj3Xyr+czWY19v4_BLscZOYqAZr2w@mail.gmail.com>
 <8AFCB26A-3808-4905-95D8-F3533AD40C47@tzi.org>
 <CABCOCHTDezF7XPvdzd7s4sDZGraALXdup9r+NvSAr3hBUyHVCQ@mail.gmail.com>
In-Reply-To: 
 <CABCOCHTDezF7XPvdzd7s4sDZGraALXdup9r+NvSAr3hBUyHVCQ@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Sat, 7 Feb 2026 11:07:48 -0800
Message-ID: 
 <CABCOCHQBCx7aOfw2k7D7Nvvx_Fd3-U66UohS2YJhBBzt6ENPHg@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Content-Type: multipart/alternative; boundary="000000000000d523d1064a409fa6"
Message-ID-Hash: VWWESZXGZU6VKV6UTRPX6PFKHEHQ4I5R
CC: Michael Richardson <mcr+ietf@sandelman.ca>,
 "yang-tooling@ietf.org" <yang-tooling@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5Byang-tooling=5D_Re=3A_file_name_conventions_for_sid-file-versio?=
	=?utf-8?q?n?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/yang-tooling/wC7JLv3_CTm_Y-YR8ix8zA-j64w>

--000000000000d523d1064a409fa6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

.....

> 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=C3=BC=C3=9Fe, Carsten
>>
>>
> Andy
>
>


Andy

--000000000000d523d1064a409fa6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">.....</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_quote"><div>In the real world YANG modules are not nearly as glob=
al as the IETF imagines.</div></div></div></blockquote><div><br></div><div>=
Actually the IETF is aware now, and the YANG Semver work deals with multipl=
e release trains</div><div>and non-backward compatible changes.</div><div><=
br></div><div>But adding nodes to a grouping is a normal BC change.</div><d=
iv>Maybe there=C2=A0should be YANG guideline not to do this for exported gr=
oupings,</div><div>but that does not really solve anything.</div><div><br><=
/div><div>I think the megarange tool needs to generate the new SID file wit=
h the current module set</div><div>even if the revision is the same as the =
last SID file.=C2=A0=C2=A0</div><div>Any differences and the sid-file-versi=
on needs to increment.</div><div><br></div><div>A simple hack I thought of =
-- have the tooling generate warnings to update the revision date</div><div=
>on the &#39;top&#39; module (or even generate the new YANG file).=C2=A0</d=
iv><div>Avoid the use of sid-file-version whenever possible.</div><div>=C2=
=A0</div><div>It is more than confusing that the contents of foo@some-date =
depend on the date you compile it, not the</div><div>revision date.=C2=A0 I=
t is critical for SID files.</div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>Th=
e same (modname, revision-date) does not always resolve to the same content=
s.</div><div>These systems rely on &lt;get-schema&gt; or copying and alteri=
ng the YANG modules as needed.</div><div><br></div><div><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">
Gr=C3=BC=C3=9Fe, Carsten<br>
<br></blockquote><div><br></div><div>Andy</div><div>=C2=A0</div></div></div=
></blockquote><div><br></div><div><br></div><div>Andy</div><div>=C2=A0</div=
></div></div>

--000000000000d523d1064a409fa6--