Subject: [Netmod-ver-dt] Another alternative versioning scheme [was Re: A more flexible form of Semantic Versioning?]

From: Robert Wilton <[email-masked]>
Date: Mon, 1 Oct 2018 11:44:39 +0100

I've re-read semver.org and my conclusion of the real value of semver is 
to know whether or not a change is going to be a breaking change from 
the version number alone.

For the semver scheme to properly work then, my interpretation is:
  - all new functionality (breaking or non breaking) is added at the 
head of the development.
  - it doesn't really support branching.
  - the expectation is that the major version number is only incremented 
when a non backwards compatible change has occurred.
  - flip-flopping (to allow nbc changes in an older release) is against 
the spirit of the semver rules, and breaks the implied ordering.

In last Thursday's meeting (and this thread), I was arguing for allowing 
a more flexible form of semver.  I.e. allowing the major version number 
to be arbitrarily incremented (e.g. for each software release) and to 
contain gaps.

However, this has the same problem that a 4 digit version number does, 
in that a module version number alone no longer indicates whether or not 
an update will be backwards compatible.  So it loses the main benefit of 
semver, and clients won't ever be able to rely on the version number 
following semver rules, even in the case where it is being strictly 
followed.

---

So, I've got another alternative idea for you to consider ;-)

Each module have two new versioning related statements:
   "version" that provides a 3 digit, partially ordered version number, 
i.e. X.Y.Z
   "semver" - if present, it indicates that the "version" field follows 
strict semantic versioning rules.

If the "semver" stmt is present then the 3 digit version number follows 
strict semantic versioning rules (e.g. as defined in the clacla draft, 
used in OpenConfig, and would probably be used in most SDO modules).

If the "semver" stmt is absent then the 3 digit module version number 
does not follow semver rules.  I.e. nothing in the version number 
implies that a change is backwards compatible or non backwards 
compatible, clients would be required to compare the modules to 
determine whether a change is backwards compatible or not.  The only 
requirement is that the version number is partially ordered (i.e. if if 
Y is incremented then Z is reset to 0, if X is incremented then Y and Z 
are both reset to 0).  It is up to the module owner to decide (and 
perhaps state) what scheme is used to increment the version numbers.  
E.g. they might decide to interpret 'X.Y.Z' as 'RELEASE.FEATURE.BUGFIX', 
allowing for non backwards compatible features or bugfixes to be made.

Any thoughts/opinions on this scheme?

Thanks,
Rob

On 24/09/2018 16:50, Juergen Schoenwaelder wrote:
> On Mon, Sep 24, 2018 at 03:56:33PM +0100, Robert Wilton wrote:
>
>>> It is a business decision; was Juniper not versioning by JunOS release?
>> Yes, but I think that they were doing this by changing the namespace for
>> each JunOS release which is arguably even more impactful that just changing
>> a version number.
> If you know upfront that things are versioned this way, I am not sure
> this approach is more impactful than having some other versioning
> mechanism in place. Would be nice to know how well this work for
> Juniper, they have years of experience...
>
> /js
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 1 Oct 2018 15:35:04 +0200

On Mon, Oct 01, 2018 at 11:44:39AM +0100, Robert Wilton wrote:
>   "version" that provides a 3 digit, partially ordered version number, i.e.
> X.Y.Z
> strict semantic versioning rules (e.g. as defined in the clacla draft, used
> in OpenConfig, and would probably be used in most SDO modules).
> 
> If the "semver" stmt is absent then the 3 digit module version number does
> not follow semver rules.  I.e. nothing in the version number implies that a
> change is backwards compatible or non backwards compatible, clients would be
> required to compare the modules to determine whether a change is backwards
> compatible or not.  The only requirement is that the version number is
> partially ordered (i.e. if if Y is incremented then Z is reset to 0, if X is
> incremented then Y and Z are both reset to 0).  It is up to the module owner
> to decide (and perhaps state) what scheme is used to increment the version
> numbers.  E.g. they might decide to interpret 'X.Y.Z' as
> 'RELEASE.FEATURE.BUGFIX', allowing for non backwards compatible features or
> bugfixes to be made.
>

And the value of a version number without any clear semantics is what
exactly? Simply use a module tag if semantics do not matter.

/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/>

---

From: Robert Wilton <[email-masked]>
Date: Mon, 1 Oct 2018 15:05:31 +0100

> exactly? Simply use a module tag if semantics do not matter.
I'm not sure what you mean by a module tag, but I perceive that the 
value is:
  - I think that it can be sufficient for vendor models. Contrast that 
to semver, which I don't think can really be made to work for vendor 
models without breaking the fundamental rules/benefits of semver.
  - It is flexible enough to allows modules that want to use semver to 
do so.
  - The version string is partially ordered like semver (which wouldn't 
apply to an arbitrary string), allowing tooling to order two arbitrary 
module versions.
  - The syntax of the version string is compatible with the semver 
subset described in the clacla draft, which should/may simplify tooling.

I don't think that a single unified versioning scheme will work well for 
all the different sources of YANG models.

If you think that my "non-semver version number scheme" is too vague 
then rather having a "semver" YANG stmt, we could instead have a 
"version-type" stmt this chooses between the different types of version 
string that are supported , e.g. "semver" or "release-based", etc.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 1 Oct 2018 18:03:59 +0200

On Mon, Oct 01, 2018 at 03:05:31PM +0100, Robert Wilton wrote:
> I'm not sure what you mean by a module tag, but I perceive that the value
> is:

I mean <draft-ietf-netmod-module-tags-02.txt>.

>  - I think that it can be sufficient for vendor models. Contrast that to
> semver, which I don't think can really be made to work for vendor models
> without breaking the fundamental rules/benefits of semver.
>  - It is flexible enough to allows modules that want to use semver to do so.
>  - The version string is partially ordered like semver (which wouldn't apply
> to an arbitrary string), allowing tooling to order two arbitrary module
> versions.
>  - The syntax of the version string is compatible with the semver subset
> described in the clacla draft, which should/may simplify tooling.
> 
> I don't think that a single unified versioning scheme will work well for all
> the different sources of YANG models.

My point is that having a number that has no defined meaning is pretty
useless from an interoperability point of view.

> If you think that my "non-semver version number scheme" is too vague then
> rather having a "semver" YANG stmt, we could instead have a "version-type"
> stmt this chooses between the different types of version string that are
> supported , e.g. "semver" or "release-based", etc.

Standards that have no semantic meaning are pretty useless standards
for me and we already have a way for publishing opaque tags. The
proposal to support a possibly open ended set of versioning schemes
does not look like a big win either. Again, we need to be clear for
which kind of clients we carry versioning numbers. The smart high-end
clients do not need them, the other clients want something that can be
reasonably checked without much complicated code - otherwise they will
just check the OS version and use that as a proper approximation. I
would not want to deal with N different version number schemes in a
client.

/js

---

From: Robert Wilton <[email-masked]>
Date: Mon, 1 Oct 2018 17:58:53 +0100

> I mean <draft-ietf-netmod-module-tags-02.txt>.
Ah, OK.  But I'm not really sure how that helps.

> useless from an interoperability point of view.
I'm not convinced.

I think that I am trying to standardize a basic format of a version 
number, but leave the high level semantics potentially undefined.

> would not want to deal with N different version number schemes in a
Clients are one consumer of version numbers.  The other significant 
consumer of version numbers are developers and operators.

My conclusion is that no single versioning scheme is best for all types 
of modules.  Considering the options:

1) I think that the existing RFC 7950 YANG scheme breaks because you 
can't fix or change anything. I don't even agree with the idea of making 
backwards compatible fixes via new config data nodes.  Having two config 
nodes representing the same underlying item of configuration seems 
flawed to me, or at least I can't figure out how it works.  If there is 
a workable scheme for this then please share it.

2) Semver is broken for vendor models.  It also does not strictly allow 
any non backwards compatible bug fix to an older release.  A solution 
that doesn't work for vendor modules isn't much use because it is vendor 
models in particular that struggle with the existing RFC 7950 rules, 
although the OpenConfig models also ignore them.

3) 4 digit semver breaks the semver rules, so you might as we well go 
for a "release.feature.bugfix" versioning scheme, allowing non backwards 
compatible changes.

4) My prior suggestion of "flexible semver" allowing arbitrary 
increments to semver's major version number helps probably make semver 
usable for vendor modules, but also breaks the semver rules so we might 
as well drop semver and use a simpler "release.feature.bugfix" 
versioning scheme instead.

5) "release.feature.bugfix" probably works for vendor models, but is 
incompatible with what OpenConfig is doing (that we should try and 
support, since it is plausible that they will be the main contender for 
standard device models).  It also requires a module/scheme diff solution 
to actually figure out if a change is backwards compatible or not.  In 
fact, should the requirements draft list OC versioning compatibility as 
a SHOULD requirement?

6) Diffing the module or schema works but is much more complex, and 
would need false positives to be mitigated via annotations (which 
probably requires some sort of version annotation on the modules).

In summary, I don't think that it is possible to have both a numeric 
versioning scheme that can indicate whether changes are backwards 
compatible or not as well allowing for bugfixes/feature enhancements to 
older branches of code.  I think that we have different types of models 
with different development practices and lifecycles.  Hence, the need 
for different versioning schemes for these different development 
approaches isn't an entirely surprising conclusion. I.e. semver is good 
where it can be used, but where it can't be used we need something else.

If anyone has an alternative solution that may solve the versioning 
issue then please share it.

Thanks,
Rob

---

From: Joe Clarke <[email-masked]>
Date: Mon, 1 Oct 2018 15:23:25 -0400

> Any thoughts/opinions on this scheme?

A semver boolean is very helpful when true and very nebulous when false.
 It would be better to have defined rules for all versioning schemes.
In that way, you have an enum or identity for what type of versioning
you use.

The upside of that is there must be some structure/reference of the
versioning scheme.  The downside is it could/will lead to a
proliferation of schemes.

Joe

> _______________________________________________
> Netmod-ver-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod-ver-dt

---

From: Joe Clarke <[email-masked]>
Date: Mon, 1 Oct 2018 15:26:24 -0400

On 10/1/18 10:05, Robert Wilton wrote:
>>> does

Yeah, this is what I was indicating in my previous email.  IMHO, a
semver or "wild west" scheme is not good.

I tend to agree that one scheme likely won't work for all vendors.
Having this flexibility would certainly be vendor-friendly.  Consumers
might not like the proliferation, though.  Sure, they will have some
documentation to which to refer that explains the scheme, but then they
have to manage within that scheme.

And in a multi-vendor network, multi-SDO network, that will be a challenge.

Still, I'm not opposed to this as this is what vendors do today with how
they version software.  For that reason, it may not be completely
unpalatable for consumers.

Joe

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 1 Oct 2018 23:48:26 +0200

> Ah, OK. But I'm not really sure how that helps.

Module tags are our there for posting arbitrary blobs of information
without clear semantics.

> I think that I am trying to standardize a basic format of a version number,
> but leave the high level semantics potentially undefined.

Yes, this is what I am saying. Having a number or a sequence of
numbers without semqntics is relatively pointless.

> Clients are one consumer of version numbers.  The other significant consumer
> of version numbers are developers and operators.
> 
> My conclusion is that no single versioning scheme is best for all types of
> modules.  Considering the options:
> 
> 1) I think that the existing RFC 7950 YANG scheme breaks because you can't
> fix or change anything. I don't even agree with the idea of making backwards
> compatible fixes via new config data nodes.  Having two config nodes
> representing the same underlying item of configuration seems flawed to me,
> or at least I can't figure out how it works.  If there is a workable scheme
> for this then please share it.
> 
> 2) Semver is broken for vendor models.  It also does not strictly allow any
> non backwards compatible bug fix to an older release.  A solution that
> doesn't work for vendor modules isn't much use because it is vendor models
> in particular that struggle with the existing RFC 7950 rules, although the
> OpenConfig models also ignore them.
> 
> 3) 4 digit semver breaks the semver rules, so you might as we well go for a
> "release.feature.bugfix" versioning scheme, allowing non backwards
> compatible changes.
> 
> 4) My prior suggestion of "flexible semver" allowing arbitrary increments to
> semver's major version number helps probably make semver usable for vendor
> modules, but also breaks the semver rules so we might as well drop semver
> and use a simpler "release.feature.bugfix" versioning scheme instead.
> 
> incompatible with what OpenConfig is doing (that we should try and support,
> since it is plausible that they will be the main contender for standard
> device models).  It also requires a module/scheme diff solution to actually
> figure out if a change is backwards compatible or not.  In fact, should the
> requirements draft list OC versioning compatibility as a SHOULD requirement?
> 
> 6) Diffing the module or schema works but is much more complex, and would
> need false positives to be mitigated via annotations (which probably
> requires some sort of version annotation on the modules).
> 
> 
> versioning scheme that can indicate whether changes are backwards compatible
> or not as well allowing for bugfixes/feature enhancements to older branches
> of code.  I think that we have different types of models with different
> development practices and lifecycles.  Hence, the need for different
> versioning schemes for these different development approaches isn't an
> entirely surprising conclusion. I.e. semver is good where it can be used,
> but where it can't be used we need something else.
> 
> If anyone has an alternative solution that may solve the versioning issue
> then please share it.
>

Perhaps there is no standard solution. So be it. Lets post vendor
specific version numbers in vendor specific module tags and we see
what is used and how.

/js

---

From: Robert Wilton <[email-masked]>
Date: Tue, 2 Oct 2018 10:18:55 +0100

> Module tags are our there for posting arbitrary blobs of information
I don't think that is really a good solution for this problem, and would 
argue that this is probably misusing tags.

> numbers without semqntics is relatively pointless.
OK, so if I was to write a tool to manage different versions of modules, 
knowing a partial ordering of module version numbers is much better than 
having no ordering at all.

> Perhaps there is no standard solution. So be it.
But what I propose of supporting several different versioning schemes is 
a solution.  It may not be the simplest solution, and I appreciate that 
you may not like it, but it does look like it would potentially work.  
At least I would argue that it is worth exploring and presenting to the 
working group.  In fact, I would like us to document in a draft the 
different solutions that we have considered and the pro's and con's of 
those solutions.  If you want to document using module tags as a 
potential solution then that is also fine with me.

>   Lets post vendor
I doubt vendors would do this, I suspect that they would be more likely 
to follow the OpenConfig approach and each define bespoke extension 
statements, all the time not strictly following the RFC 7950 module 
update rules.  But I don't see how that helps clients, or operators, at all.

I still think that the solution of supporting multiple versioning 
schemes (ideally all restricted to use an X.Y.Z numerical format) is a 
pragmatic solution.  Perhaps defining two different formats (one of 
which is semver) is sufficient for the likely versioning schemes that 
will be encountered.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Tue, 2 Oct 2018 10:57:12 +0100

> semver or "wild west" scheme is not good.
OK, so lets keep strict semver as one option, and see if we can define 
one of two weaker versioning schemes that are sufficient for the vendors.

Scheme1: strict semver (major.minor.patch):
    - 'major' is only incremented for nbc changes or nbc bugfixes 
('minor', 'patch' reset to 0).  Must include nbc changes.
    - 'minor' is only incremented for bc features or bc bugfixes 
('patch' reset to 0).  Must only include bc changes.
    - 'patch' is only incremented for cosmetic fixes.  Must not include 
any change to API semantics.
    Note: nbc bugfixes are restricted to major releases only.

Scheme 2: partial semver (release.minor.patch):
    - 'release' is only incremented for each major release ('minor', 
'patch' reset to 0).  May include nbc changes.
    - 'minor' is only incremented whenever a bc feature or bc bugfixes 
('patch' reset to 0).  Must only include bc changes.
    - 'patch' is only incremented for cosmetic fixes.  Must not include 
any change to API semantics.
    Note: nbc bugfixes are restricted to major releases only.

Scheme 3: weakest semver (release.major.minor):
    - 'release' is only incremented for each major release ('major', 
'minor' reset to 0).  May include nbc changes.
    - 'major' is only incremented for nbc changes or nbc bugfixes 
('minor' reset to 0).  Must include nbc changes.
    - 'minor' is only incremented for bc features or bc bugfixes. Must 
only include bc changes.
    Note: nbc bugfixes are allowed on branches.

-----

Or an alternative way to express this would be a 4 element version field 
(release.major.minor.patch):
    - 'release' is only incremented for each major release ('major' 
'minor', 'patch' reset to 0).  May include nbc changes.
    - 'major' is only incremented for nbc changes or nbc bugfixes 
('minor', 'patch' reset to 0).  Must include nbc changes.
    - 'minor' is only incremented for bc features or bc bugfixes 
('patch' reset to 0).  Must only include bc changes.
    - 'patch' is only incremented for cosmetic fixes.  Must not include 
any change to API semantics.

For models that want to follow the strict semver scheme, they would 
always keep "release" set as 0, to the (major.minor.patch) follow the 
semver rules.
For models that want to follow partial semver, they would always keep 
"major" set to 0, limiting nbc changes to within a release.
For models that want the weakest form of semver, all 4 fields are usable.

Perhaps this is very close to Jason's original suggestion.

Thanks,
Rob

> .

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Oct 2018 12:08:51 +0200

> argue that this is probably misusing tags.

Why not? Perhaps the problem is too hard to solve and vendors are fine
defining their specific version numbering schemes in the space we have
for such things.

> having no ordering at all.

But not much. If I see n persons in a certain order and I have no idea
what the order means, the order is still relatively useless at the end.

> But what I propose of supporting several different versioning schemes is a
> solution.  It may not be the simplest solution, and I appreciate that you
> may not like it, but it does look like it would potentially work.  At least
> I would argue that it is worth exploring and presenting to the working
> group.  In fact, I would like us to document in a draft the different
> solutions that we have considered and the pro's and con's of those
> solutions.  If you want to document using module tags as a potential
> solution then that is also fine with me.

Lets assume that there is not a single versioning scheme that people
will be happy with. Then this is first of all pretty bad news. So now
we are talking about lets work out N common versioning schemes and
define the rules for all of them plus add support for ordered numbers
for any proprietary versioning schemes we may have missed. This could
be done, I am however concerned that (a) we may not get all the
versioning schemes right and (b) it may be more practical to have
different organizations or vendors define their versioning schemes
instead of the IETF trying to build a collection of versioning
schemes. And it matters how big N is going to be. The bigger N, the
more painful things will be for systems using the N different
versioning schemes.

> I doubt vendors would do this, I suspect that they would be more likely to
> follow the OpenConfig approach and each define bespoke extension statements,
> all the time not strictly following the RFC 7950 module update rules.  But I
> don't see how that helps clients, or operators, at all.

>From a highlevel perspective, there is not much difference between:

  oc-ext:openconfig-version "5.0.1";

and a module tag vendor:openconfig:version 5.0.1. Yes, an extension
statement is an integral part of a YANG module while a module tag is
something tied to a YANG module and more flexible (can be modified or
removed) but from a highlevel perspective, both version numbers are
module annotations. Tags may actually pretty cool in tagging which
client versions are known to work with a module, i.e.:

  vendor:acme:bgpdebugger:version "2.3,2.5-2.6.1"

I am looking for a solution that makes it easy for a client to
determine whether it has a reasonable chance to work with a given
server. And this is a difficult question to answer and YANG version
numbers only help marginally with this. Your tool that analyzes the
entire schema against the schema requirements of a client could
generate such client version tags.
 
> I still think that the solution of supporting multiple versioning schemes
> (ideally all restricted to use an X.Y.Z numerical format) is a pragmatic
> solution.  Perhaps defining two different formats (one of which is semver)
> is sufficient for the likely versioning schemes that will be encountered.

So what we would have to do is to

(a) refactor RFC 7950 so that it (i) defines what NBC changes are and
    which ones are not and (ii) defines the traditional versioning
    model where NBC changes are not allowed.

(b) create a SEMVER versioning model that describes how SEMVER version
    numbers work and the definition refers to the common definition of
    NBC changes

(c) create a branching versioning model that describes how branches
    with some form of version numbers work and the definition refers
    to the common definition of NBC changes

(d) create a release versioning model that buids on OS release numbers
    and the definition refers to the common definition of NBC changes

(perhaps we also need a common definition what bug fixes are)

And then we have your tool that does a full schema analysis and
comparison to generate something like 'work-with-client-xyz'
compatibility indicator.

I am concerned about the complexity of all of this and the time needed
to work all of this out. Perhaps building a full schema analysis and
comparison tool to generate compatibility indicators is a much more
general and at the end also more timely answer.

/js

---

From: Robert Wilton <[email-masked]>
Date: Wed, 3 Oct 2018 14:51:55 +0100

> defining their specific version numbering schemes in the space we have
But would this mean that import by version would need to become import 
by tag?

> what the order means, the order is still relatively useless at the end.
I'm not convinced of this point.

>      model where NBC changes are not allowed.
Yes, but we mostly have those definitions already today.
>      numbers work and the definition refers to the common definition of
Yes, but semver.org and the clacala draft have done quite a lot of the 
heavy lifting on this already.

>      and the definition refers to the common definition of NBC changes
So, my assumption is that a branching versioning scheme and release 
versioning scheme are basically two different facets of the same thing.

As per my other email, perhaps it is possible to unify semantic 
versioning and release based versioning under a 4 number version identifier.

> (perhaps we also need a common definition what bug fixes are)
Yes, I think that there should be some text describing how to classify a 
bug fix as backwards compatible or not.  Such a human based definition 
may differ from what tooling would classify the change as.

> comparison to generate something like 'work-with-client-xyz'
Yes.

> general and at the end also more timely answer.
Well I do think that ultimately this is the most general solution. But 
even with this I think that there still needs to be an human readable 
way to label and refer to different versions of a module. I don't think 
that revision dates work because they assume a linear progression.  I do 
think that a partially ordered 3 (or 4) number version string would 
likely be sufficient.

Thanks,
Rob

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 4 Oct 2018 13:45:09 +0000

Hi guys,

I'm not an expert on the tags draft (have read it quickly) but it isn't clear to me how different tags can be associated with different versions of a module. The module-tags only has a module name as a key. 

I guess BGP version "A" might have tag "....:semver:1.0.0" in the YANG file while BGP version "B" might have tag "...:semver:2.0.0" ?  But they when you read the module-tags from a server would it return all the semver tags for all the versions that the server supports ?

Jason

> -----Original Message-----
> From: Netmod-ver-dt <[email-masked]> On Behalf Of
> Robert Wilton
> Sent: Wednesday, October 3, 2018 9:52 AM
> To: Juergen Schoenwaelder <[email-masked]>;
> [email-masked]
> Subject: Re: [Netmod-ver-dt] Another alternative versioning scheme [was Re:
> A more flexible form of Semantic Versioning?]
> 
> 
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 4 Oct 2018 10:03:04 -0400

Rob and all:

BGP standard changes will occur to older specification and modules.   

My example of Flow specification being changed and new additions being added to both the older and the new.   Can this functionality can be supported by either of schemes?  

I'm really agnostic to streams id or keeping the 3 digits.   The vendors should decide on that 

Sue Hares
(IDR co-chair hat). 

-----Original Message-----
From: Netmod-ver-dt [mailto:[email-masked]] On Behalf Of Robert Wilton
Sent: Monday, October 1, 2018 6:45 AM
To: [email-masked]
Subject: [Netmod-ver-dt] Another alternative versioning scheme [was Re: A more flexible form of Semantic Versioning?]

I've re-read semver.org and my conclusion of the real value of semver is to know whether or not a change is going to be a breaking change from the version number alone.

For the semver scheme to properly work then, my interpretation is:
  - all new functionality (breaking or non breaking) is added at the head of the development.
  - it doesn't really support branching.
  - the expectation is that the major version number is only incremented when a non backwards compatible change has occurred.
  - flip-flopping (to allow nbc changes in an older release) is against the spirit of the semver rules, and breaks the implied ordering.

In last Thursday's meeting (and this thread), I was arguing for allowing a more flexible form of semver.  I.e. allowing the major version number to be arbitrarily incremented (e.g. for each software release) and to contain gaps.

However, this has the same problem that a 4 digit version number does, in that a module version number alone no longer indicates whether or not an update will be backwards compatible.  So it loses the main benefit of semver, and clients won't ever be able to rely on the version number following semver rules, even in the case where it is being strictly followed.

---

Each module have two new versioning related statements:
   "version" that provides a 3 digit, partially ordered version number, i.e. X.Y.Z
   "semver" - if present, it indicates that the "version" field follows strict semantic versioning rules.

If the "semver" stmt is present then the 3 digit version number follows strict semantic versioning rules (e.g. as defined in the clacla draft, used in OpenConfig, and would probably be used in most SDO modules).

If the "semver" stmt is absent then the 3 digit module version number does not follow semver rules.  I.e. nothing in the version number implies that a change is backwards compatible or non backwards compatible, clients would be required to compare the modules to determine whether a change is backwards compatible or not.  The only requirement is that the version number is partially ordered (i.e. if if Y is incremented then Z is reset to 0, if X is incremented then Y and Z are both reset to 0).  It is up to the module owner to decide (and perhaps state) what scheme is used to increment the version numbers. E.g. they might decide to interpret 'X.Y.Z' as 'RELEASE.FEATURE.BUGFIX', allowing for non backwards compatible features or bugfixes to be made.

Thanks,
Rob

On 24/09/2018 16:50, Juergen Schoenwaelder wrote:
>> Yes, but I think that they were doing this by changing the namespace 
>> for each JunOS release which is arguably even more impactful that 
>> just changing a version number.