Note, adding it to the meta-data YANG definition does not mean that
everyone has to populate this, it just ensures that it has a consistent
name and semantics for clients/servers that do want to use it.
Thanks,
Rob
On 26/06/2018 16:38, Balazs Lengyel wrote:
Any opinions on Rob's suggestion about a free-text versioning string?
I am neutral on this.
regards Balazs
On 6/26/2018 5:31 PM, Robert Wilton wrote:
On 26/06/2018 16:20, Balazs Lengyel wrote:
On 6/26/2018 4:07 PM, Robert Wilton wrote:
7) It might want to include a semantic version number for an
instance-data-set, depending on whether the YANG
versioning discussions
ends up.
BALAZS: Yes I would like to. However I am not exactly
clear on what does
backwards compatibility mean for instance data.
Data MAY NOT be removed or changed only added. ???
Who would use the semver numbers ???
What does the version number mean? Every change of instance data
in an
instacne-data-set leads to a new version number? What is a bug
fix in
this sense? What is a non-backwards compatible change of
instance data?
I am left a bit puzzled.
Probably I don't mean semantic version. But often files have
versioning, or
revision, information associated with them. This can be muxed
into the file
name/path, but it also seems like potentially useful metadata,
and being
able to handle this generically in a consistent way might be
beneficial.
As an example, perhaps the capability information related to S/W
release
1.2.4, etc.
We need to separate a version number of the instance data from the a
version number (or version context) that may be needed in order to
understand what a YANG (module, path) tuple means if we move to a
different YANG versioning scheme. The later I agree would be needed,
the former I am less sure of - at least if we talk semantic version
numbers.
Yes, I agree with the need for the latter, that may entail listing
the versions of the modules in the meta-data.
But what I was actually referring to was the former, and thinking
more of it is just being a string field in the meta-data with a
well defined name, that is optional to populate. Actually, I see
the current definition already has a revision with a date and
description string. This is roughly along the lines of what I was
thinking of for versioning (although I'm not sure why this should
be a list rather than just a pair of leaves).
Thanks,
Rob
BALAZS: IMHO if we want to use versioning (semver) to version the
instance-data-set itself we first need to understand what backwards
compatibility means for an instance data set.
So, I'm suggesting versioning, but not semver. Just a string version
field. E.g. for XR I would just put in the XR release number
"R4.5.1" or similar.
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email:[email protected]
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
