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

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to