On Mon, Jun 22, 2020 at 04:01:59PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote: > Hi Juergen, > > Section 5 in the link below attempts to explain how to manage this (but > always happy for review of that text to help improve it). > > The key is to always ensure there is a unique version for every revision that > exists. > > In your example below it would go like this: > > I have RFCXXXX at version 1.0.0. I make some backwards compatible changes: > 1.0.0
I use the same version number until I make an incompatible change? > I then make a backwards incompatible change: > 1.1.0-XXXXbis-dev1 > > Then I add more backwards compatible changes: > 2.0.0-XXXXbis-dev2 > > Then I remove the backwards incompatible change: > 1.1.0-XXXXbis-dev3 > > When the module is finally published as an RFC it would just be version 1.1.0 > in this case. > > The main problems covered: > - ensure all intermediate versions have a unique identifier (in case there > are pre-release implementations, etc) > - ensure the final version has the correct YANG Semver > /js -- 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
