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 <[email protected]>
> Cc: [email protected]
> 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 <[email protected]>
> > Sent: Monday, June 22, 2020 12:30 PM
> > To: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]>
> > Cc: [email protected]
> > 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: +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
