On Wed, Apr 1, 2020 at 10:39 AM Joe Clarke (jclarke) <[email protected]> wrote:
> > > > 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. > > IMO it is confusing to ignore the semver rules for the special 0.x.y releases. There are many NBC changes made at this point which are treated as minor or patch changes. The procedure is really broken once you consider a WG developing any RFC-bis module. Now the major version is not 0 and all updates look like real releases. > My take would align to yours that we wouldn’t clutter a module with > development NBC tracking. > > Joe Andy
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
