Hi,
below is my last call review.
Document: draft-ietf-netmod-yang-semver-06
Date: 2022-03-06
* 1. Introduction
s/for updating modules/for updating YANG modules/
s/extended [semver] rules/extended semantic versioning rules [semver]/
Thanks for the text pointing out that the semantic versioning specs
change in non-backwards-compatible ways without bumping the version
of the versioning specs. Its like saying "the truth about semantic
versioning rules is that they are merely guidelines but not any hard
rules".
BTW, is it Semver or SemVer? And since this is not really SemVer,
should there be an acronym that makes it clear that this is not
really SemVer?
* 3.1. YANG Semver Pattern
It may be useful to spell out where you follow [semver] and where
not. The _COMPAT suffix seems to be something new that I did not
spot in [semver].
I am somewhat surprised by the _COMPAT suffix that can declare a
patch update to be non-compatible. [semver] says that Z is for
"backwards compatible bug fixes". If so, how can you have a
backwards compatible bug fix that is not backwards compatible?
* 3.2. Examples for YANG semantic versions
Looking at the version number alone does not indicate ancestry. The
module definition in "2.0.0", for example, does not contain all the
contents of "1.3.0". Version "2.0.0" is not derived from "1.3.0".
So how do we identify branching points? How do I tell that 2.0.0 was
derived from 1.2.0? If we can't construct the order from the version
labels, will not some of things in the versioning document break, in
particular if I throw a bunch of _non_compatible suffixes into the
mix as well?
What is the reason that we talk about "editorial updates" instead of
"bug fixes" (which seems to be the [semver] terminology)? Even worse,
how can 'editorial updates' be _non_compatible?
I understand that SemVer fails to work well once you have not a
single development line (where all NBC changes go into the next
major number increase) but you have to maintain multiple development
lines where each development line can have NBC changes within it.
In short, you would need SemVers for each development line. It seems
this document acknowledges that multiple development lines exist but
then proposes to handle this reality by collapsing entire
development lines into _non_compatible markers for series of
patches.
* 6. YANG Module
rev:revision-label "1.0.0-draft-ietf-netmod-yang-semver-05";
This is wrong, we are already at -06. ;-) I guess these revision
labels will be commonly wrong if they need to be updated manually
and we have no tooling in place to verify consistency.
* 7. Contributors
- Typo 'Discussons'
- Perhaps just list the names of the contributors comma separated
instead of making this a longish list.
* 9.1. YANG Module Registrations
The ietf-yang-semver module defines the prefix 'ysver' but the IANA
section suggests to register 'yangver'. Why not simply 'semver'? The
'rev' prefix also does not start with a 'y'. Anyway, whatever is
picked, the prefix and the IANA registration should be consistent.
On Mon, Feb 21, 2022 at 12:20:38PM -0500, Lou Berger wrote:
> All,
>
> This starts working group last call on
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/
>
> The working group last call ends on March 7 th.
> Please send your comments to the working group mailing list.
>
> Positive comments, e.g., "I've reviewed this document
> and believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
>
> Please note that once WG Last call is complete, this document will be held
> and submitted as a set with the other versioning documents (once they are
> ready) for publication request to the IESG.
>
> Thank you,
> Lou (Co-Chair & doc Shepherd)
>
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
--
Jürgen Schönwälder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
