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
