Hey, Jürgen. I wanted to respond back to your comments on YANG Semver with
some concrete answers based on the -19 revision.
* YANG Semantic Versioning
<draft-ietf-netmod-yang-semver-17>
- The claims made in the first paragraph of the abstract about the
versioning document do not seem to be aligned with that document
when it says "a more flexible approach to importing modules by
revision". My understanding is that the versioning document says
that collections of suitable modules are maintained outside of
YANG modules and there is a recommended-min-date, which is a piece
of documentation but not changing YANG's current import logic.
[JMC] Fixed. We used the same sentence from module versioning.
- I am still confused by the complexity introduced here. Why do we
need both X.Y.Z and X.Y.Z_compatible? What is the difference, when
do I use which?
[JMC] We arrived at the need for modifiers based on the original requirements.
That said, we added clarity around how and when to use modifiers in our new
Appendix B.
- X.Y.Z_non_compatible sounds like a somewhat questionable idea. To
me, this says "we claim this is X.Y.Z but we know it should be
something different". The _non_compatible modifier essentially
overwrites the meaning of [SemVer], rendering X.Y.Z at best into a
branch identifier. Perhaps this is what the industry really wants,
three digit branch identifiers but not really [SemVer]?
[JMC] This is that additional branching support that was part of the original
requirements. In the overwhelming majority of cases you would use X.Y.Z. In
fact, I believe in all IETF cases, only X.Y.Z would be used. It’s best to
describe the “why” of the _compatible modifier with specific numbers. Let’s
say you have a module versioned 1.2.3 and you want to add a feature (i.e., make
an otherwise MINOR change). However, module 1.3.0 has already been published.
In this case, you would publish a 1.2.4_compatible. This might be a very real
case with vendor modules.
- The example in Section 4.4.1 is interesting and welcome but
unfortunately there is no recommendation how situations should be
handled if branches split off (and perhaps even merge later).
[JMC] We did not want to get overly prescriptive with software development, but
we added text to the now Section 4.4.3 to make people aware that these
branching limitations exist. Plus, we showed two scenarios in Appendix B as to
how the branching limitations come into play.
- If I need to make a BC update to X.Y.Z_compatible but
X.Y.Z+1_non_compatible has already been taken, what do I do?
[JMC] We addressed this in Appendix B. We admit that not all cases are
possible, but offered a suggestion nonetheless.
- I am not sure how the recommended-min-version helps if there are
branches since there is not guarantee that 2.0.0 > v1.1.1 implies
that 2.0.0 includes everything that was in 1.1.1. If
recommended-min-version is 1.1.1, then an import of 2.0.0 may
still fail, no?
[JMC] As this draft evolved over time, we went from a very prescriptive syntax
to something looser based on feedback and discussion. We fully admit this
won’t address all cases, but it does help with SDO modules where there isn’t
[typically] branching.
- An existing compliant YANG compiler will not "locate a module with
a version that is viable according to the conditions above". An
existing compiler YANG compiler will ignore the extension
statements recommended-min-version (and recommended-min-date). I
think you need to acknowledge this and word things differently.
Sure, a compiler that supporting recommended-min-version may
generate suitable warnings, but existing compliant YANG 1.1 and
YANG 1 compilers can't be expected to do something fancy due to
the presence of an (from the compiler's perspective) unknown
extension.
[JMC] We fixed that text to state that this approach would be for a compiler
that is aware and supports the extension.
- Is 'ys' a good module prefix? Yes, it is YANG's variation of
SemVer, but perhaps ys is a bit too cryptic? What about 'semver'
or if we optimistically assume we do not need another versioning
scheme even just 'ver' (the reverse of 'rev').
rev:non-backwards-compatible rev:non-backwards-compatible
rev:recommended-min-date rev:recommended-min-date
ys:version 3.1.0 semver:version 3.1.0
ys:recommended-min-version semver:recommended-min-version
[JMC] We’ve gone back and forth on extension names a few times. We wanted
something short that was somewhat descriptive. We realize “ys” might have
erred too much on the short side. We settled on “ysv” this time around. We
didn’t want “semver” as we think the idea of “YANG Semver” is important as we
have rules that are unique to this scheme.
- Description of the version extension:
"The version extension can be used to provide an additional
identifier associated with a module or submodule
revision.
I am not sure about "additional identifier". Its just a version
number. So what about:
"The version extension can be used to assign a version number
to a module or submodule revision.
[JMC]. Grr. Now I realize that in my final push I didn’t have this new text.
So this is not yet addressed in -19, but will be in -20. We are going with
your suggestion.
- I like the choice ietf-yang-library-semver, see my suggestion to
use ietf-yang-library-status for the other yang library extension
above. I also like the yl-semver prefix here, I do not like so
much the ys-conf prefix used in the other draft. Some consistency
may be nice.
[JMC] We are looking at ys-conf as part of YANG module versioning.
- Editorial
s/do not not require/do not require/
[JMC] Fixed.
Joe
_______________________________________________
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
