Re: [netmod] YANG Versioning: filename recommendations for YANG Semver

[Andy Bierman <[e-mail]>]

On Tue, Apr 2, 2024 at 2:11 PM Joe Clarke (jclarke) <[e-mail]>
wrote:

> Thanks, Andy.  See inline below.
>
>
>
> I do not agree with these recommendations to change the file names of YANG
> modules.
>
> The OFFICIAL YANG version is RFC 7950 - YANG 1.1.
>
> Any module using YANG version 1.1 needs to follow the rules in RFC 7950.
>
> Additional file naming that can be ignored by YANG 1.1 tools is OK.
>
>
>
> [JMC] We had this conversation on our call today.  I agree with you that
> tools can be unaware of YANG Semver and attempt to load a file named
> foo#1.2.3.yang as a module named “foo#1.2.3”, which would disagree with the
> module name defined within the module.
>
>
>

This can never happen since the '#' char is not allowed in a YANG module
name.
YANG 1.1 tools look for MODNAME[@DATE].EXT.
If the YANG module name is not in this format the tool will not find the
module.

The issue is obviously not the 2 lines of code to parse "#" instead of "@".
IMO this file name change is operationally disruptive and not really needed.
How come OpenConfig modules do not use this naming scheme?
Is it because they are following the RFC 7950 file naming rules?



> [JMC] Therefore, I’d be more in favor of no strong language on
> recommendations for YANG Semver within filenames.  Instead, to avoid a de
> facto standard in the industry, I’d prefer language such as, “if you want
> to insert YANG Semver into the module filename, then the format MUST be
> MODULE_NAME#SEMVER.yang.”  Any recommendation would be to remain consistent
> to 7950 and additionally publish the file with @REVSION.
>
>
>
> I do not understand how a 1:1 deterministic mapping is achieved, based on
> the YANG SemVer spec:
>
>
>
>
> https://www.ietf.org/archive/id/draft-ietf-netmod-yang-semver-15.html#name-yang-semver-pattern
>
>
>
>        1.0.3
>
>        1.0.3_compatible
>
>        1.0.3_non_compatible
>
>
>
> [JMC] These three versions cannot happen for a given module.  Only one of
> them can exist based on the rules.  If 1.0.3 already exists, then the next
> version could only be 1.0.4_compatible or 1.0.4_non_compatible (assuming
> you want to do BC or NBC changes in the 1.0 MAJOR.MINOR branch).
>
>
>
> The SemVer draft is confusing.
>
>
>
>       YANG artifacts that employ semantic versioning as defined in this
> document MUST use a version identifier
>
>       that corresponds to the following pattern: 'X.Y.Z_COMPAT'.
>
>
>
> And also:
>
>
>
>       Additionally, [SemVer] defines two specific types of metadata that
> may be appended to a semantic version string.  ....
>
>
>
> Examples from sec 6:
>
>
>       1.0.0-alpha.1
>
>       1.0.0-alpha.3
>
>       2.1.0-beta.42
>
>       3.0.0-202007.rc.1
>
>
>
>
>
> How do these strings conform to the pattern specified in sec. 4.3?
>
>
>
> [JMC] This additional build metadata is ignored for the purposes of YANG
> Semver, but I get your point.  I think some text should be added to address
> this optional metadata.
>
>
>

So the revision-date is the only field that can be relied upon since the
same SemVer (e.g. "1.0.0") could be released several times,
each one containing different content.


Joe
>


Andy