Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-03-02

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 3 Mar 2021 16:01:00 +0000

YANG Versioning Weekly Call Minutes - 2021-03-02

Meeting notes from Tuesday's meeting on YANG versioning.

Regarding the NBC changes text (that have been discussed over email)
 - We are close to agreement that the current text
 - It was agreed that having a paragraph to reference the pre-release markers would be useful
Next step: Joe has the action of:
   - Merging Rob's pull request
   - Fixing XML to v3 format (e.g., rerun conversion tool)
   - Adding a paragraph to reference pre-release markers.
 
There was further discussion as to whether the "rev:nbc-changes" marker MAY be added even when it is known that there are no nbc-changes.

The consensus of the folk on the call (but Jason was absent) is that it should only be added when the changes are known to be, or suspected that they may be, non-backwards-compatible.
Next step: Still trying to reach consensus
 
We discussed changing "rev:nbc-changes" marker to expand nbc, and avoid potential confusion.
There is agreement to expand the tag, but there were two proposed expanded versions, and there didn't seem to be strong consensus for, or against, either of them:
The two choices are:
  rev:non-backwards-compatible;
  rev:non-backwards-compatible-changes;
 - Reshad has the action of changing the module versioning doc to one of these.  Semver doc will also need to be updated.

Rob to send IANA text to WG (now done).

We also discussed Reshad's proposed slides for IETF 110.  Of particular note was the discussion regarding whitespace:
 - Tom commented that the build metadata could be used to indicate where another version of a YANG module has been published with whitespace changes.
 - It was noted that this might help with Semver version numbers, but the impact to revision date also need to be considered.
 - No conclusion on this, future discussion with the WG on this issue is likely needed.

We also discussed a couple of issues that were raised by Joseph (in the context of the Semver 2.0.0 github repository):

1. Is Semver 2.0.0 a stable reference, or is the specification being changed without changing the version number.  Joe to check, whether the current Semver 2.0.0 specification seems to be stable.

2. Check whether our usage of pre-release labels is aligned with Semver 2.0.0, or requires tweaking.  Action is on Joe to check.

Rob