On 6/26/18 11:38, Balazs Lengyel wrote: > Any opinions on Rob's suggestion about a free-text versioning string? > I am neutral on this.
Like I mentioned, I would use this for YANG Catalog input, and I would want MD around yang-library instance data. That MD would include the vendor, platform, and version of software. I'm not asking for all of these to be standardized, though. I would just want a way to extend the MD as needed. Joe > > 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 > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
