Re: [netmod] module-versioning should require any solution to describe labels for drafts

["Sterne, Jason (Nokia - CA/Ottawa)" <[e-mail]>]

Hi all,

In our weekly call this week we debated the format of the yang semver for updates & new modules.

We found a corner case in the proposal below and would suggest a slight modification: 
- include either the authors name (for non-adopted drafts) or the word 'ietf' for adopted drafts, and
- use the draft # as a suffix.  For example:
    1.1.0-smith-XXXXbis-03

So the general scheme is:
    A.B.C-<author name or 'ietf'>-XXXXbis-yy
where:
    A.B.C = the current estimated final SemVer digits for the new RFC
    <author name or 'ietf'> = before a draft is adopted it has a name like draft-smith-foo-03 and after it is adopted it becomes draft-ietf-netmod-foo-00.  Pre-adoption use 'smith' in the revision-label and post-adoption use 'ietf'.
    XXXX = the RFC being updated
    yy = the draft version number

Another alternative we came up with that is simple and avoids all potential collisions is this:
    A.B.C-<full draft name>
For example: 
    1.1.0-draft-smith-foo-03

It will make for long revision-labels and more importantly long file names, but it is very simple and easy to follow.

Our inclination at the moment is to prescribe the A.B.C part and then say that all draft and published versions must have a unique revision-label.  Then provide those two methods as example of how to achieve unique labels.

Jason

> -----Original Message-----
> From: Sterne, Jason (Nokia - CA/Ottawa)
> Sent: Monday, June 22, 2020 12:39 PM
> To: Juergen Schoenwaelder <[e-mail]>
> Cc: [e-mail]
> Subject: RE: [netmod] module-versioning should require any solution to
> describe labels for drafts
> 
> Sorry - I messed that up with my copy-n-pasting and editing.  Let me try that
> again 😊
> 
> I have RFCXXXX at version 1.0.0.
> 1.0.0
> 
>  I make some backwards compatible changes.
> 1.1.0-XXXXbis-dev1
> 
> I then make a backwards incompatible change.
> 2.0.0-XXXXbis-dev2
> 
> Then I add more backwards compatible changes.
> 2.0.0-XXXXbis-dev3
> 
> Then I remove the backwards incompatible change.
> 1.1.0-XXXXbis-dev4
> 
> Then if we published the RFC at that point it would be 1.1.0
> 
> Jason
> 
> 
> > -----Original Message-----
> > From: Juergen Schoenwaelder <[e-mail]>
> > Sent: Monday, June 22, 2020 12:30 PM
> > To: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>
> > Cc: [e-mail]
> > Subject: Re: [netmod] module-versioning should require any solution to
> describe
> > labels for drafts
> >
> > 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://www.jacobs-university.de/>