> On Apr 1, 2020, at 13:28, Andy Bierman <[email protected]> wrote: > > Hi, > > I just want to confirm that all the proposed documentation procedures > using new extensions are limited in scope to published modules only, > and not applied to unpublished modules (terms defined in RFC 8407). > > IMO it would be harmful to module usability to assign revision-labels or > include revision-related extensions in unpublished modules (e.g., Internet > Drafts). > Consider how cluttered and confusing the client-server modules would be > if the 50+ NBC changes and versions were tracked through all the I-Ds. > > For IETF modules, the first usage of the revision-label > should be in the initial RFC, and be set to 1.0.0. > > If the RFC is ever republished then one can expect to find an updated > revision-label and possibly extensions tracking NBC changes.
The semver scheme allocates a major version of 0 for pre-releases where the BC/NBC rules do not apply. I agree that a first official RFC release should be 1.0.0 (from a semver revision-label standpoint). From a design team standpoint, I know we mentioned the 0 versioning early on, but I don’t think we spent much time talking about modules under development overall. My take would align to yours that we wouldn’t clutter a module with development NBC tracking. Joe _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
