Subject: Re: [Netmod-ver-dt] definition of Non-Backwards-Compatible

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 11 Oct 2018 14:48:59 +0000

OOC why backwards (with an ‘s’), isn’t the proper term backward? I’m fine with the hyphen.

From: Netmod-ver-dt <[email-masked]> on behalf of "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Friday, October 5, 2018 at 9:51 AM
To: "[email-masked]" <[email-masked]>
Subject: [Netmod-ver-dt] definition of Non-Backwards-Compatible

Hi all,

Here is some proposed text to define non-backwards-compatible.

First of all let's agree on the exact terms we will use. I'd propose these (with hyphens, with an 's'):
  "backwards-compatible"
  "non-backwards-compatible"

https://semver.org/ has the term "backwards-compatible" in their summary.

Example in a sentence:  "Renaming a leaf is a non-backwards-compatible change."

Should we use "nbc" as a short form in any documents ? Probably not…

In the Requirements draft we should add a section called "Terminology" with the following proposed text:

--------------------------------------------------
The following terms are used within this document:

- non-backwards-compatible: In the context of this document, the term 'non-backwards-compatible' refers to a change or set of changes between two YANG modules that do not adhere to the list of allowable definition revisions specified in Section 11 "Updating a Module" of RFC7950, with the following exceptions and clarifications:
    - adding a "status" statement with a value of "obsolete", or changing a "status" statement from some other value to "obsolete", is considered a non-backwards-compatible change
    - the impact (to backwards-compatibility) of adding a "status" statement with a value of "deprecated", or changing a "status" statement from some other value to "deprecated" is TBD (future study ? depends on the server behavior ?).

-------------------------------------------------------------------------

Do we need to somehow specifically mention or refer to this paragraph from section 11 ? In theory it isn't in the "list of allowable definition revisions" (which is the bulleted list after the sentence that ends "… may be revised in any of the following ways:"):

    Otherwise, if the semantics of any previous definition are changed
   (i.e., if a non-editorial change is made to any definition other than
   those specifically allowed above), then this MUST be achieved by a
   new definition with a new identifier.

I was also wondering if we should say anything about the very last paragraph of section 11. I was surprised when I saw that reordering isn't allowed.  Does this mean you can't simply reorder 2 leafs ?

   In statements that have any data definition statements as
   substatements, those data definition substatements MUST NOT be
   reordered.  If new data definition statements are added, they can be
   added anywhere in the sequence of existing substatements.

Regards,
Jason

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 11 Oct 2018 15:08:15 +0000

I don't feel strongly about 'backward' vs 'backwards'. My gut was 'backwards' but there is possibly more use out there for 'backward'.

I went with what I saw here:
    https://semver.org/ has the term "backwards-compatible" in their summary.

RFC7950 uses 'backward' without the 's' though (but it also uses 'backward-incompatible' and I think we should avoid that term).

Jason

From: Reshad Rahman (rrahman) <[email-masked]>
Sent: Thursday, October 11, 2018 10:49 AM
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]
Subject: Re: [Netmod-ver-dt] definition of Non-Backwards-Compatible

From: Netmod-ver-dt <[email-masked]<mailto:[email-masked]>> on behalf of "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 5, 2018 at 9:51 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Netmod-ver-dt] definition of Non-Backwards-Compatible

Hi all,

Regards,
Jason