> On Jun 22, 2020, at 11:41, Juergen Schoenwaelder > <[email protected]> wrote: > > I have RFCXXXX at version 1.0.0. I make some backwards compatible > changes. I then make a backwards incompatible change. Then I add more > backwards compatible changes. Then I remove the backwards incompatible > change. What are the resulting version numbers?
If this is done in development, your version may look like 2.0.0-RFCXXXXbis-dev1 or 1.1.0-RFCXXXXbis-dev5 (depending on what your final intent is). For in-development work, the only things the new text mandates are using the ‘-‘ pre-release notation and making sure any released module (i.e., one that appears in a rev of the I-D in Data Tracker) has a unique version number across its entire lifetime. The rules of MAJOR.MINOR.PATCH do not strictly apply here since this is pre-release work. > > Rhetoric question: How many IETF module authors will get this all done > correctly during module revision (and which problem does all of this > fix)? The reason for the unique version even for development is so someone implementing or using this module knows exactly which module and version has been implemented. Joe > > /js > > On Mon, Jun 22, 2020 at 03:24:33PM +0000, Sterne, Jason (Nokia - CA/Ottawa) > wrote: >> Hi guys, >> >> In the latest working copy of the YANG Semver draft we added some text in >> section 5 about how to select revision labels for modules that are under >> development, or for RFCs that are churning (i.e. bis versions). >> >> https://github.com/netmod-wg/yang-ver-dt/blob/master/yang-semver/draft-ietf-netmod-yang-semver.txt >> >> I think we probably need to require that same information for any revision >> label scheme. I'd suggest we put something along these lines into the >> module-versioning draft: >> >> Any revision label scheme MUST describe how labels are selected for new YANG >> modules that are under development, and how labels are selected for modules >> in IETF RFCs that are being updated (e.g. a "bis" version is under >> development). >> >> (should we drop the "in IETF RFCs" ? ) >> >> Jason >> > >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod > > > -- > Juergen Schoenwaelder 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
