Closed rgwilton closed 5 years ago
OK, I think that I will try and generalize this text (just tracked as an issue for the moment).
If some vendors don't want to use YANG semver for module versioning, then I suspect that they may not want to use YANG smever for package versioning either.
My intent is that packages sort of follow the approach/split defined by module-versioning + YANG-semver. A module definition doesn't currently carry the fully revision history, but it does mark whether the version is nbc to the previous version or not, potentially allowing the full revision history to be reconstructed, if required.
Section 5.3:
Hmmm, while I agree with the semver rule text, one COULD use a version string that is not semver at all. Then how do these rules apply? I think we either need to make semver mandatory to implement with a separate revision-label for vendors, or we generalize this text.