From f834dc99d1c1a9022724b107aff550a7e0d75e06 Mon Sep 17 00:00:00 2001 From: Joe Clarke Date: Wed, 17 Feb 2021 09:56:08 -0500 Subject: [PATCH] Address some issues. * Add text for Issue #61 to adress semver gaps. * Add text for Issue #59 to provide guidance for IANA modules and how they are versioned. [1] Submitted by: Rob Wilton [1] --- yang-semver/draft-ietf-netmod-yang-semver.txt | 372 +++++---- yang-semver/draft-ietf-netmod-yang-semver.xml | 734 ++++++++++-------- 2 files changed, 631 insertions(+), 475 deletions(-) diff --git a/yang-semver/draft-ietf-netmod-yang-semver.txt b/yang-semver/draft-ietf-netmod-yang-semver.txt index 11a1f11..92db761 100644 --- a/yang-semver/draft-ietf-netmod-yang-semver.txt +++ b/yang-semver/draft-ietf-netmod-yang-semver.txt @@ -6,18 +6,18 @@ Network Working Group B. Claise Internet-Draft J. Clarke, Ed. Updates: 8407 (if approved) R. Rahman Intended status: Standards Track R. Wilton, Ed. -Expires: 17 April 2021 Cisco Systems, Inc. +Expires: 21 August 2021 Cisco Systems, Inc. B. Lengyel Ericsson J. Sterne Nokia K. D'Souza AT&T - 14 October 2020 + 17 February 2021 YANG Semantic Versioning - draft-ietf-netmod-yang-semver-01 + draft-ietf-netmod-yang-semver-02 Abstract @@ -41,11 +41,11 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 17 April 2021. + This Internet-Draft will expire on 21 August 2021. Copyright Notice - Copyright (c) 2020 IETF Trust and the persons identified as the + Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. @@ -53,9 +53,9 @@ Copyright Notice -Claise, et al. Expires 17 April 2021 [Page 1] +Claise, et al. Expires 21 August 2021 [Page 1] -Internet-Draft YANG Semver October 2020 +Internet-Draft YANG Semver February 2021 This document is subject to BCP 78 and the IETF Trust's Legal @@ -86,12 +86,15 @@ Table of Contents 6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 - 10.2. Informative References . . . . . . . . . . . . . . . . . 17 - Appendix A. Example IETF Module Development . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 9.1. YANG Module Registrations . . . . . . . . . . . . . . . . 17 + 9.2. Guidance for YANG Semver in IANA maintained YANG + modules . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 10.2. Informative References . . . . . . . . . . . . . . . . . 18 + Appendix A. Example IETF Module Development . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction @@ -103,20 +106,20 @@ Table of Contents from where a specific revision of a YANG module is derived. Additionally, section 3.3 of [I-D.ietf-netmod-yang-module-versioning] defines a revision label which can be used as an overlay or alias to - provide additional context or an additional way to refer to a - specific revision. - -Claise, et al. Expires 17 April 2021 [Page 2] +Claise, et al. Expires 21 August 2021 [Page 2] -Internet-Draft YANG Semver October 2020 +Internet-Draft YANG Semver February 2021 + provide additional context or an additional way to refer to a + specific revision. + This document defines a revision-label scheme that uses modified [semver] rules for YANG artifacts (i.e., YANG modules and YANG - packages [I-D.ietf-netmod-yang-packages]) as well as the revision + packages [I-D.ietf-netmod-yang-packages] ) as well as the revision label definition for using this scheme. The goal of this is to add a human readable version label that provides compatibility information for the YANG artifact without one needing to compare or parse its @@ -134,7 +137,7 @@ Internet-Draft YANG Semver October 2020 Additionally, this document uses the following terminology: * YANG artifact: YANG modules, YANG packages - [I-D.ietf-netmod-yang-packages], and YANG schema elements are + [I-D.ietf-netmod-yang-packages] , and YANG schema elements are examples of YANG artifacts for the purposes of this document. 3. YANG Semantic Versioning @@ -160,16 +163,16 @@ Internet-Draft YANG Semver October 2020 0x5f) and MUST only present if the following COMPAT element is included - * COMPAT, if it is specified, MUST be either the literal string - "compatible" or the literal string "non_compatible" - -Claise, et al. Expires 17 April 2021 [Page 3] +Claise, et al. Expires 21 August 2021 [Page 3] -Internet-Draft YANG Semver October 2020 +Internet-Draft YANG Semver February 2021 + * COMPAT, if it is specified, MUST be either the literal string + "compatible" or the literal string "non_compatible" + Additionally, [semver] defines two specific types of metadata that may be appended to a semantic version string. Pre-release metadata MAY be appended to a semver string after a trailing '-' character. @@ -177,7 +180,7 @@ Internet-Draft YANG Semver October 2020 both pre-release and build metadata are present, then build metadata MUST follow pre-release metadata. While build metadata MUST be ignored by YANG semver parsers, pre-release metadata MUST be used - during module development and MUST be considered base on Section 5. + during module development and MUST be considered base on Section 5 . Both pre-release and build metadata are allowed in order to support all of the [semver] rules. Thus, a version lineage that follows strict [semver] rules is allowed for a YANG artifact. @@ -209,7 +212,7 @@ Internet-Draft YANG Semver October 2020 artifact versions that are not the latest. However, it does not provide for the unlimited branching and updating of older revisions which are documented by the general rules in - [I-D.ietf-netmod-yang-module-versioning]. + [I-D.ietf-netmod-yang-module-versioning] . * YANG artifacts that follow the [semver] versioning scheme are fully compatible with implementations that understand the YANG @@ -218,12 +221,9 @@ Internet-Draft YANG Semver October 2020 - - - -Claise, et al. Expires 17 April 2021 [Page 4] +Claise, et al. Expires 21 August 2021 [Page 4] -Internet-Draft YANG Semver October 2020 +Internet-Draft YANG Semver February 2021 * If updates are always restricted to the latest revision of the @@ -277,9 +277,9 @@ Internet-Draft YANG Semver October 2020 -Claise, et al. Expires 17 April 2021 [Page 5] +Claise, et al. Expires 21 August 2021 [Page 5] -Internet-Draft YANG Semver October 2020 +Internet-Draft YANG Semver February 2021 restructuring how a module uses, or does not use, submodules is @@ -333,9 +333,9 @@ Internet-Draft YANG Semver October 2020 -Claise, et al. Expires 17 April 2021 [Page 6] +Claise, et al. Expires 21 August 2021 [Page 6] -Internet-Draft YANG Semver October 2020 +Internet-Draft YANG Semver February 2021 0.1.0 @@ -389,9 +389,9 @@ Internet-Draft YANG Semver October 2020 -Claise, et al. Expires 17 April 2021 [Page 7] +Claise, et al. Expires 21 August 2021 [Page 7] -Internet-Draft YANG Semver October 2020 +Internet-Draft YANG Semver February 2021 1.2.1_non_compatible - backport NBC fix, changing "baz" to "bar" @@ -445,12 +445,19 @@ Internet-Draft YANG Semver October 2020 -Claise, et al. Expires 17 April 2021 [Page 8] +Claise, et al. Expires 21 August 2021 [Page 8] -Internet-Draft YANG Semver October 2020 +Internet-Draft YANG Semver February 2021 - 3. If an artifact is being updated in a backwards-compatible way, + 3. An artifact author MAY choose to skip version numbers. That is, + an artifact's revision history can include 1.0.0, 1.1.0, and + 1.3.0 where 1.2.0 is skipped. Note that doing so has an impact + when importing modules by revision-or-derived. See Section 4 for + more details on importing modules with revision-label version + gaps. + + 4. If an artifact is being updated in a backwards-compatible way, then the next version number depends on the format of the current version number: @@ -465,7 +472,7 @@ Internet-Draft YANG Semver October 2020 iii "X.Y.Z_non_compatible" - the artifact version MUST be updated to "X.Y.Z+1_non_compatible". - 4. If an artifact is being updated in an editorial way, then the + 5. If an artifact is being updated in an editorial way, then the next version number depends on the format of the current version number: @@ -477,7 +484,7 @@ Internet-Draft YANG Semver October 2020 iii "X.Y.Z_non_compatible" - the artifact version MUST be updated to "X.Y.Z+1_non_compatible". - 5. YANG artifact semantic version numbers beginning with 0, i.e + 6. YANG artifact semantic version numbers beginning with 0, i.e "0.X.Y" are regarded as beta definitions and need not follow the rules above. Either the MINOR or PATCH version numbers may be updated, regardless of whether the changes are non-backwards- @@ -492,20 +499,19 @@ Internet-Draft YANG Semver October 2020 Below is a sample YANG module that uses the YANG semver revision label based on the rules defined in this document. + + +Claise, et al. Expires 21 August 2021 [Page 9] + +Internet-Draft YANG Semver February 2021 + + module example-versioned-module { yang-version 1.1; namespace "urn:example:versioned:module"; prefix "exvermod"; rev:revision-label-scheme "yangver:yang-semver"; - - - -Claise, et al. Expires 17 April 2021 [Page 9] - -Internet-Draft YANG Semver October 2020 - - import ietf-yang-revisions { prefix "rev"; } import ietf-yang-semver { prefix "yangver"; } @@ -549,19 +555,18 @@ Internet-Draft YANG Semver October 2020 rev:revision-label "1.1.0"; } - revision 2017-04-03 { - description "First release version."; - rev:revision-label "1.0.0"; - } - - -Claise, et al. Expires 17 April 2021 [Page 10] +Claise, et al. Expires 21 August 2021 [Page 10] -Internet-Draft YANG Semver October 2020 +Internet-Draft YANG Semver February 2021 + revision 2017-04-03 { + description "First release version."; + rev:revision-label "1.0.0"; + } + // Note: semver rules do not apply to 0.X.Y labels. revision 2017-01-30 { @@ -605,18 +610,17 @@ Internet-Draft YANG Semver October 2020 revision label or has that label in its revision history can be used to satisfy the import requirement. For example: - import example-module { - rev:revision-or-derived "3.0.0"; - } - - -Claise, et al. Expires 17 April 2021 [Page 11] +Claise, et al. Expires 21 August 2021 [Page 11] -Internet-Draft YANG Semver October 2020 +Internet-Draft YANG Semver February 2021 + + import example-module { + rev:revision-or-derived "3.0.0"; + } Note: the import lookup does not stop when a non-backward-compatible change is encountered. That is, if module B imports a module A at or @@ -624,11 +628,18 @@ Internet-Draft YANG Semver October 2020 revision of module A with version 2.1.0_non_compatible in order to determine if the present instance of module A derives from 2.0.0. + If an import by revision-or-derived cannot locate the specified + revision-label in a given module's revision history, that import will + fail. This is noted in the case of version gaps. That is, if a + module's history includes 1.0.0, 1.1.0, and 1.3.0, an import from + revision-or-derived at 1.2.0 will be unable to locate the specified + revision entry and thus the import cannot be satisfied. + 5. Guidelines for Using Semver During Module Development This section and the IETF-specific sub-section below provides YANG semver-specific guidelines to consider when developing new YANG - modules. As such this section updates [RFC8407]. + modules. As such this section updates [RFC8407] . Development of a brand new YANG module outside of the IETF that uses YANG semver as its revision-label scheme SHOULD begin with a 0 for @@ -656,6 +667,13 @@ Internet-Draft YANG Semver October 2020 2.1.0-beta.42 + + +Claise, et al. Expires 21 August 2021 [Page 12] + +Internet-Draft YANG Semver February 2021 + + 3.0.0-202007.rc.1 When developing a new revision of an existing module using the YANG @@ -666,14 +684,6 @@ Internet-Draft YANG Semver October 2020 development MAJOR version component must be 2 with some pre-release notation such as -alpha.1, making the version 2.0.0-alpha.1. That said, every publicly available release of a module MUST have a unique - - - -Claise, et al. Expires 17 April 2021 [Page 12] - -Internet-Draft YANG Semver October 2020 - - YANG semver revision-label (where a publicly available release is one that could be implemented by a vendor or consumed by an end user). Therefore, it may be prudent to include the year or year and month @@ -712,6 +722,14 @@ Internet-Draft YANG Semver October 2020 is being revised to include non-backwards-compatible changes in draft-user-netmod-foo, its development revision-labels MUST include 2.0.0-draft-user-netmod-foo followed by the document's revision + + + +Claise, et al. Expires 21 August 2021 [Page 13] + +Internet-Draft YANG Semver February 2021 + + (e.g., 2.0.0-draft-user-netmod-foo-02). This will ensure each pre- release version is unique across the lifecycle of the module. Even when using the 0 MAJOR version for initial module development (where @@ -722,16 +740,8 @@ Internet-Draft YANG Semver October 2020 If a module is being revised and the original module never had a revision-label (i.e., you wish to start using YANG semver in future module revisions), choose a semver value that makes the most sense - - - -Claise, et al. Expires 17 April 2021 [Page 13] - -Internet-Draft YANG Semver October 2020 - - based on the module's history. For example, if a module started out - in the pre-NMDA ([RFC8342]) world, and then had NMDA support added + in the pre-NMDA ([RFC8342] ) world, and then had NMDA support added without removing any legacy "state" branches -- and you are looking to add additional new features -- a sensible choice for the target YANG semver would be 1.2.0 (since 1.0.0 would have been the initial, @@ -769,6 +779,13 @@ Internet-Draft YANG Semver October 2020 Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved. + + +Claise, et al. Expires 21 August 2021 [Page 14] + +Internet-Draft YANG Semver February 2021 + + Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License @@ -779,13 +796,6 @@ Internet-Draft YANG Semver October 2020 This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; - - -Claise, et al. Expires 17 April 2021 [Page 14] - -Internet-Draft YANG Semver October 2020 - - // RFC Ed.: update the date below with the date of RFC publication // and remove this note. // RFC Ed.: replace XXXX with actual RFC number and remove this @@ -824,6 +834,14 @@ Internet-Draft YANG Semver October 2020 } description "Represents a YANG semantic version number. The rules governing the + + + +Claise, et al. Expires 21 August 2021 [Page 15] + +Internet-Draft YANG Semver February 2021 + + use of this revision label scheme are defined in the reference for this typedef."; reference @@ -832,16 +850,6 @@ Internet-Draft YANG Semver October 2020 } - - - - - -Claise, et al. Expires 17 April 2021 [Page 15] - -Internet-Draft YANG Semver October 2020 - - 7. Contributors This document grew out of the YANG module versioning design team that @@ -871,11 +879,11 @@ Internet-Draft YANG Semver October 2020 * Rob Wilton The initial revision of this document was refactored and built upon - [I-D.clacla-netmod-yang-model-update]. + [I-D.clacla-netmod-yang-model-update] . Discussons on the use of Semver for YANG versioning has been held with authors of the OpenConfig YANG models based on their own - [openconfigsemver]. We would like thank both Anees Shaikh and Rob + [openconfigsemver] . We would like thank both Anees Shaikh and Rob Shakir for their input into this problem space. 8. Security Considerations @@ -883,20 +891,77 @@ Internet-Draft YANG Semver October 2020 The document does not define any new protocol or data model. There are no security impacts. + + +Claise, et al. Expires 21 August 2021 [Page 16] + +Internet-Draft YANG Semver February 2021 + + 9. IANA Considerations - None. +9.1. YANG Module Registrations -10. References + The following YANG module is requested to be registred in the "IANA + Module Names" registry: -10.1. Normative References + Name: ietf-yang-semver + + XML Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-semver + + Prefix: yangver + + Reference: [RFCXXXX] +9.2. Guidance for YANG Semver in IANA maintained YANG modules + Note for IANA (to be removed by the RFC editor): Please check that + the registries and IANA YANG modules are referenced in the + appropriate way. -Claise, et al. Expires 17 April 2021 [Page 16] + IANA is responsible for maintaining and versioning some YANG modules, + e.g., iana-if-types.yang [IfTypeYang] and iana-routing-types.yang + [RoutingTypesYang] . + + In addition to following the rules specified in the IANA + Considerations section of [I-D.ietf-netmod-yang-module-versioning] , + IANA maintained YANG modules MUST also include a YANG Semver revision + label for all new revisions, as defined in Section 3 . + + The YANG Semver version associated with the new revision MUST follow + the rules defined in Section 3.3 . + + Note: For IANA maintained YANG modules that have already been + published, revision labels MUST be retrospectively applied to all + existing revisions when the next new revision is created, starting at + version "1.0.0" for the initial published revision, and then + incrementing according to the YANG Semver version rules specified in + Section 3.3 . + + Most changes to IANA maintained YANG modules are expected to be + backwards-compatible changes and classified as MINOR version changes. + The PATCH version may be incremented instead when only editorial + changes are made, and the MAJOR version would be incremented if non- + backwards-compatible major changes are made. + + + + + + +Claise, et al. Expires 21 August 2021 [Page 17] -Internet-Draft YANG Semver October 2020 +Internet-Draft YANG Semver February 2021 + + Given that IANA maintained YANG modules are versioned with a linear + history, it is anticipated that it should not be necessary to use the + "_compatible" or "_non_compatible" modifiers to the "Z_COMPAT" + version element. + +10. References + +10.1. Normative References [I-D.ietf-netmod-yang-module-versioning] Wilton, R., Rahman, R., Lengyel, B., Clarke, J., Sterne, @@ -932,9 +997,23 @@ Internet-Draft YANG Semver October 2020 [I-D.ietf-netmod-yang-packages] Wilton, R., Rahman, R., Clarke, J., Sterne, J., and W. Bo, "YANG Packages", Work in Progress, Internet-Draft, draft- - ietf-netmod-yang-packages-00, 17 March 2020, + ietf-netmod-yang-packages-01, 2 November 2020, . + packages-01>. + + + + + +Claise, et al. Expires 21 August 2021 [Page 18] + +Internet-Draft YANG Semver February 2021 + + + [IfTypeYang] + "iana-if-type YANG Module", + . [openconfigsemver] "Semantic Versioning for Openconfig Models", @@ -945,14 +1024,12 @@ Internet-Draft YANG Semver October 2020 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . - [semver] "Semantic Versioning 2.0.0", . - - - -Claise, et al. Expires 17 April 2021 [Page 17] - -Internet-Draft YANG Semver October 2020 + [RoutingTypesYang] + "iana-routing-types YANG Module", + . + [semver] "Semantic Versioning 2.0.0", . Appendix A. Example IETF Module Development @@ -978,6 +1055,17 @@ Appendix A. Example IETF Module Development Continued version lineage after adoption: + + + + + + +Claise, et al. Expires 21 August 2021 [Page 19] + +Internet-Draft YANG Semver February 2021 + + 1.0.0-draft-ietf-netmod-example-module-00 | 1.0.0-draft-ietf-netmod-example-module-01 @@ -1000,16 +1088,6 @@ Appendix A. Example IETF Module Development | | 1.1.0-draft-jdoe-netmod-exmod-enhancements-01 || 1.1.0-draft-jadoe-netmod-exmod-changes-01 - - - - - -Claise, et al. Expires 17 April 2021 [Page 18] - -Internet-Draft YANG Semver October 2020 - - At this point, the WG decides to merge some aspects of both and adopt the work in jadoe's draft as draft-ietf-netmod-exmod-changes. A single version lineage continues. @@ -1036,6 +1114,14 @@ Authors' Addresses Email: bclaise@cisco.com + + + +Claise, et al. Expires 21 August 2021 [Page 20] + +Internet-Draft YANG Semver February 2021 + + Joe Clarke (editor) Cisco Systems, Inc. 7200-12 Kit Creek Rd @@ -1058,14 +1144,6 @@ Authors' Addresses Email: rwilton@cisco.com - - - -Claise, et al. Expires 17 April 2021 [Page 19] - -Internet-Draft YANG Semver October 2020 - - Balazs Lengyel Ericsson 1117 Budapest @@ -1095,26 +1173,4 @@ Internet-Draft YANG Semver October 2020 - - - - - - - - - - - - - - - - - - - - - - -Claise, et al. Expires 17 April 2021 [Page 20] +Claise, et al. Expires 21 August 2021 [Page 21] diff --git a/yang-semver/draft-ietf-netmod-yang-semver.xml b/yang-semver/draft-ietf-netmod-yang-semver.xml index 44e484c..e7d0265 100755 --- a/yang-semver/draft-ietf-netmod-yang-semver.xml +++ b/yang-semver/draft-ietf-netmod-yang-semver.xml @@ -11,106 +11,108 @@ - - -YANG Semantic Versioning + + + YANG Semantic Versioning - - + + Cisco Systems, Inc. - -
- -De Kleetlaan 6a b1 -1831 Diegem -Belgium - - +32 2 704 5622 - bclaise@cisco.com -
- - - - Cisco Systems, Inc. -
- - 7200-12 Kit Creek Rd - Research Triangle Park - North Carolina - United States of America - - +1-919-392-2867 - jclarke@cisco.com -
- - - - + +
+ + De Kleetlaan 6a b1 + 1831 Diegem + Belgium + + +32 2 704 5622 + bclaise@cisco.com +
+ + + + Cisco Systems, Inc. +
+ + 7200-12 Kit Creek Rd + Research Triangle Park + North Carolina + United States of America + + +1-919-392-2867 + jclarke@cisco.com +
+ + + + Cisco Systems, Inc. - -
- rrahman@cisco.com -
- - - - + +
+ rrahman@cisco.com +
+ + + + Cisco Systems, Inc. - -
- rwilton@cisco.com -
- - - - Ericsson -
- - Magyar Tudosok Korutja - 1117 Budapest - Hungary - - +36-70-330-7909 - balazs.lengyel@ericsson.com -
- - - - + +
+ rwilton@cisco.com +
+ + + + Ericsson +
+ + Magyar Tudosok Korutja + 1117 Budapest + Hungary + + +36-70-330-7909 + balazs.lengyel@ericsson.com +
+ + + + Nokia - -
- jason.sterne@nokia.com -
- - - - AT&T -
- -200 S. Laurel Ave -Middletown -NJ -United States of America - - - kd6913@att.com -
- - - - - - - This document specifies a scheme and guidelines for applying a modified set of + +
+ jason.sterne@nokia.com +
+ + + + AT&T +
+ + 200 S. Laurel Ave + Middletown + NJ + United States of America + + + kd6913@att.com +
+ + + + + + + This document specifies a scheme and guidelines for applying a modified set of semantic versioning rules to revisions of YANG modules. Additionally, this document defines a revision-label for this modified semver scheme. - - - -
- puts forth a number of concepts relating + + + +
+ + + puts forth a number of concepts relating to modified rules for updating modules, a means to signal when a new revision of a module has non-backwards-compatible (NBC) changes compared to its previous revision, and a versioning scheme that uses the revision history as a lineage for determining from where a specific revision of a YANG @@ -118,21 +120,25 @@ defines a revision label which can be used as an overlay or alias to provide additional context or an additional way to refer to a specific revision. - This document defines a revision-label scheme that uses modified rules for YANG artifacts - (i.e., YANG modules and YANG packages ) as well as the + This document defines a revision-label scheme that uses modified + rules for YANG artifacts + (i.e., YANG modules and YANG packages +) as well as the revision label definition for using this scheme. The goal of this is to add a human readable version label that provides compatibility information for the YANG artifact without one needing to compare or parse its body. The label and rules defined herein represent the RECOMMENDED revision label scheme for IETF YANG artifacts.
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT - RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT + RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 + + when, and only when, they appear in all capitals, as shown here. Additionally, this document uses the following terminology: YANG artifact: YANG modules, YANG packages - , and YANG schema elements are examples of YANG artifacts + +, and YANG schema elements are examples of YANG artifacts for the purposes of this document. @@ -155,112 +161,122 @@ - Additionally, defines two specific types of metadata that may be appended to a semantic version string. + Additionally, + defines two specific types of metadata that may be appended to a semantic version string. Pre-release metadata MAY be appended to a semver string after a trailing '-' character. Build metadata MAY be appended after a trailing '+' character. If both pre-release and build metadata are present, then build metadata MUST follow pre-release metadata. While build metadata MUST be ignored by YANG semver parsers, pre-release metadata MUST be used - during module development and MUST be considered base on . Both pre-release and build metadata are allowed in order - to support all of the rules. Thus, a version lineage that follows strict rules + during module development and MUST be considered base on +. Both pre-release and build metadata are allowed in order + to support all of the + rules. Thus, a version lineage that follows strict + rules is allowed for a YANG artifact. - To signal the use of this versioning scheme, modules MUST set the revision-label-scheme extension as defined in - to the identity "yang-semver". That identity value is defined +To signal the use of this versioning scheme, modules MUST set the revision-label-scheme extension as defined in + + to the identity "yang-semver". That identity value is defined in the ietf-yang-semver module below. - Additionally, this ietf-yang-semver module defines a typedef that formally specifies the syntax of the YANG semver version string. -
+Additionally, this ietf-yang-semver module defines a typedef that formally specifies the syntax of the YANG semver version string. +
-
- This document defines the YANG semantic versioning scheme that is used for YANG +
+This document defines the YANG semantic versioning scheme that is used for YANG artifacts that employ the YANG semver label. The versioning scheme has the following properties: - - The YANG semantic versioning scheme is extended from version - 2.0.0 of the semantic versioning scheme defined at semver.org to cover the additional requirements for the + + The YANG semantic versioning scheme is extended from version + 2.0.0 of the semantic versioning scheme defined at semver.org + to cover the additional requirements for the management of YANG artifact lifecyles that cannot be addressed using the semver.org 2.0.0 versioning scheme alone. - Unlike the versioning scheme, the YANG + Unlike the + versioning scheme, the YANG semantic versioning scheme supports limited updates to older versions of YANG artifacts, to allow for bug fixes and enhancements to artifact versions that are not the latest. However, it does not provide for the unlimited branching and updating of older revisions which are documented by the general rules in - . + +. - YANG artifacts that follow the versioning +YANG artifacts that follow the + versioning scheme are fully compatible with implementations that understand the YANG semantic versioning scheme defined in this document. - If updates are always restricted to the latest revision +If updates are always restricted to the latest revision of the artifact only, then the version numbers used by the YANG semantic versioning scheme are exactly the same as those defined - by the versioning scheme. - - + by the + versioning scheme. + + - Every YANG module versioned using the YANG semantic versioning +Every YANG module versioned using the YANG semantic versioning scheme specifies the module's semantic version number as the argument to the 'rev:revision-label' statement. - Because the rules put forth in are designed to work +Because the rules put forth in + are designed to work well with existing versions of YANG and allow for artifact authors to migrate to this scheme, it is not expected that all revisions of a given YANG artifact will have a semantic version label. For example, the first revision of a module may have been produced before this scheme was available. - YANG packages that make use of this semantic versioning scheme will have their semantic version +YANG packages that make use of this semantic versioning scheme will have their semantic version as the value of the "revision_label" property. - + As stated above, the YANG semver version number is expressed as a string of the form: 'X.Y.Z_COMPAT'; where X, Y, and Z each represent non-negative integers smaller than 2147483647 without leading zeroes, and _COMPAT represents an optional suffix of either "_compatible" or "_non_compatible". - - 'X' is the MAJOR version. Changes in the major version number + +'X' is the MAJOR version. Changes in the major version number indicate changes that are non-backwards-compatible to versions with a lower major version number. - 'Y' is the MINOR version. Changes in the minor version number +'Y' is the MINOR version. Changes in the minor version number indicate changes that are backwards-compatible to versions with the same major version number, but a lower minor version number and no patch "_compatible" or "_non_compatible" modifier. - 'Z_COMPAT' is the PATCH version and modifier. Changes in the patch +'Z_COMPAT' is the PATCH version and modifier. Changes in the patch version number can indicate editorial, backwards-compatible, or non-backwards-compatible changes relative to versions with the same major and minor version numbers, but lower patch version number, depending on what form modifier "_COMPAT" takes: - - If the modifier string is absent, the change represents an + + If the modifier string is absent, the change represents an editorial change. An editorial change is defined to be a change in the YANG artifact's content that does not affect the semantic meaning or functionality provided by the artifact in any way. An example is correcting a spelling mistake in the description of a leaf within a YANG module. Note: restructuring how a module uses, or does not use, submodules is treated as an editorial level change on the condition that there is no change in the module's semantic behavior due to the restructuring. - If, however, the modifier string is present, the meaning is described below: - "_compatible" - the change represents a backwards-compatible change - "_non_compatible" - the change represents a non-backwards-compatible change - - - - - The YANG artifact name and YANG semantic version number uniquely + If, however, the modifier string is present, the meaning is described below: + "_compatible" - the change represents a backwards-compatible change + "_non_compatible" - the change represents a non-backwards-compatible change + + + + +The YANG artifact name and YANG semantic version number uniquely identify a revision of said artifact. There MUST NOT be multiple instances of a YANG artifact definition with the same name and YANG semantic version number but different content (and in the case of modules, different revision dates). - There MUST NOT be multiple versions of a YANG artifact that have +There MUST NOT be multiple versions of a YANG artifact that have the same MAJOR, MINOR and PATCH version numbers, but different patch modifier strings. E.g., artifact version "1.2.3_non_compatible" MUST NOT be defined if artifact version "1.2.3" has already been defined. -
- The following diagram and explanation illustrates how YANG semantic version numbers work. -
- Example YANG semantic version numbers for an example artifact: - +
+The following diagram and explanation illustrates how YANG semantic version numbers work. +
+Example YANG semantic version numbers for an example artifact: + 0.1.0 | 0.2.0 @@ -278,61 +294,61 @@ 3.0.0 \ 3.1.0 - -
- Assume the tree diagram above illustrates how an example YANG module's version + +
+Assume the tree diagram above illustrates how an example YANG module's version history might evolve. For example, the tree might represent the following changes, listed in chronological order from oldest revision to newest: - - 0.1.0 - first beta module version - 0.2.0 - second beta module version (with NBC changes) - 1.0.0 - first release (may have NBC changes from 0.2.0) - 1.1.0 - added new functionality, leaf "foo" (BC) - 1.2.0 - added new functionality, leaf "baz" (BC) - 1.3.0 - improve existing functionality, added leaf "foo-64" (BC) - 1.3.1 - improve description wording for "foo-64" (Editorial) - 1.1.1_compatible - backport "foo-64" leaf to 1.1.x to avoid implementing "baz" from 1.2.0 (BC) - 2.0.0 - change existing model for performance reasons, e.g. re-key list (NBC) - 1.1.2_non_compatible - NBC point bug fix, not required in 2.0.0 due to model changes (NBC) - 3.0.0 - NBC bugfix, rename "baz" to "bar"; also add new BC leaf "wibble"; (NBC) - 1.2.1_non_compatible - backport NBC fix, changing "baz" to "bar" - 1.2.2_non_compatible - backport "wibble". This is a BC change but "non_compatible" modifier is sticky. - 3.1.0 - introduce new leaf "wobble" (BC) - - - The partial ordering relationships based on the semantic versioning numbers can be defined as follows: - - 1.0.0 < 1.1.0 < 1.2.0 < 1.3.0 < 2.0.0 < 3.0.0 < 3.1.0 - 1.0.0 < 1.1.0 < 1.1.1_compatible < 1.1.2_non_compatible - 1.0.0 < 1.1.0 < 1.2.0 < 1.2.1_non_compatible < 1.2.2_non_compatible - - - There is no ordering relationship between 1.1.1_non_compatible and either 1.2.0 or + + 0.1.0 - first beta module version + 0.2.0 - second beta module version (with NBC changes) + 1.0.0 - first release (may have NBC changes from 0.2.0) + 1.1.0 - added new functionality, leaf "foo" (BC) + 1.2.0 - added new functionality, leaf "baz" (BC) + 1.3.0 - improve existing functionality, added leaf "foo-64" (BC) + 1.3.1 - improve description wording for "foo-64" (Editorial) + 1.1.1_compatible - backport "foo-64" leaf to 1.1.x to avoid implementing "baz" from 1.2.0 (BC) + 2.0.0 - change existing model for performance reasons, e.g. re-key list (NBC) + 1.1.2_non_compatible - NBC point bug fix, not required in 2.0.0 due to model changes (NBC) + 3.0.0 - NBC bugfix, rename "baz" to "bar"; also add new BC leaf "wibble"; (NBC) + 1.2.1_non_compatible - backport NBC fix, changing "baz" to "bar" + 1.2.2_non_compatible - backport "wibble". This is a BC change but "non_compatible" modifier is sticky. + 3.1.0 - introduce new leaf "wobble" (BC) + + +The partial ordering relationships based on the semantic versioning numbers can be defined as follows: + + 1.0.0 < 1.1.0 < 1.2.0 < 1.3.0 < 2.0.0 < 3.0.0 < 3.1.0 + 1.0.0 < 1.1.0 < 1.1.1_compatible < 1.1.2_non_compatible + 1.0.0 < 1.1.0 < 1.2.0 < 1.2.1_non_compatible < 1.2.2_non_compatible + + +There is no ordering relationship between 1.1.1_non_compatible and either 1.2.0 or 1.2.1_non_compatible, except that they share the common ancestor of 1.1.0. - Looking at the version number alone, the module definition in +Looking at the version number alone, the module definition in 2.0.0 does not necessarily contain the contents of 1.3.0. However, the module revision history in 2.0.0 may well indicate that it was edited from module version 1.3.0. -
-
+
+ -
- When a new revision of an artifact is produced, then the following +
+When a new revision of an artifact is produced, then the following rules define how the YANG semantic version number for the new artifact revision is calculated, based on the changes between the two artifact revisions, and the YANG semantic version number of the base artifact revision from which the changes are derived: - - - If an artifact is being updated in a non-backwards-compatible + + +If an artifact is being updated in a non-backwards-compatible way, then the artifact version "X.Y.Z[_compatible|_non_compatible]" MUST be updated to "X+1.0.0" unless that artifact version has already been defined with different content, in which case the artifact version "X.Y.Z+1_non_compatible" MUST be used instead. - Under some circumstances (e.g., to avoid adding a "_compatible" modifier) an +Under some circumstances (e.g., to avoid adding a "_compatible" modifier) an artifact author MAY also update the MAJOR version when the only changes are backwards-compatible. This is where tooling is important to highlight all changes. Because, while avoiding the "_compatible" and "_non_compatible" @@ -340,50 +356,57 @@ changes are entirely backwards-compatible may confuse end users. - If an artifact is being updated in a backwards-compatible way, +An artifact author MAY choose to skip version numbers. That is, an artifact's revision history + can include 1.0.0, 1.1.0, and 1.3.0 where 1.2.0 is skipped. Note that doing so has an impact + when importing modules by revision-or-derived. See + for more details + on importing modules with revision-label version gaps. + +If an artifact is being updated in a backwards-compatible way, then the next version number depends on the format of the current version number: - - "X.Y.Z" - the artifact version MUST be updated to "X.Y+1.0", + + "X.Y.Z" - the artifact version MUST be updated to "X.Y+1.0", unless that artifact version has already been defined with different content, when the artifact version MUST be updated to "X.Y.Z+1_compatible"" instead. - "X.Y.Z_compatible" - the artifact version MUST be updated to + "X.Y.Z_compatible" - the artifact version MUST be updated to "X.Y.Z+1_compatible". - "X.Y.Z_non_compatible" - the artifact version MUST be updated to + "X.Y.Z_non_compatible" - the artifact version MUST be updated to "X.Y.Z+1_non_compatible". - - + + - If an artifact is being updated in an editorial way, then the next +If an artifact is being updated in an editorial way, then the next version number depends on the format of the current version number: - - "X.Y.Z" - the artifact version MUST be updated to "X.Y.Z+1" - "X.Y.Z_compatible" - the artifact version MUST be updated to + + "X.Y.Z" - the artifact version MUST be updated to "X.Y.Z+1" + "X.Y.Z_compatible" - the artifact version MUST be updated to "X.Y.Z+1_compatible". - "X.Y.Z_non_compatible" - the artifact version MUST be updated to + "X.Y.Z_non_compatible" - the artifact version MUST be updated to "X.Y.Z+1_non_compatible". - - + + - YANG artifact semantic version numbers beginning with 0, i.e +YANG artifact semantic version numbers beginning with 0, i.e "0.X.Y" are regarded as beta definitions and need not follow the rules above. Either the MINOR or PATCH version numbers may be updated, regardless of whether the changes are - non-backwards-compatible, backwards-compatible, or editorial. See for + non-backwards-compatible, backwards-compatible, or editorial. See + for more details on using this notation during module development. - - -
-
-
- Below is a sample YANG module that uses the YANG semver revision label + + +
+
+
+Below is a sample YANG module that uses the YANG semver revision label based on the rules defined in this document. - + -
- +
+ module example-versioned-module { yang-version 1.1; namespace "urn:example:versioned:module"; @@ -451,16 +474,16 @@ } //YANG module definition starts here - -
-
-
- Below is an example YANG package that uses the semver revision label based on + + +
+
+Below is an example YANG package that uses the semver revision label based on the rules defined in this document. - + -
- +
+ { "ietf-yang-instance-data:instance-data-set": { "name": "example-yang-pkg", @@ -480,7 +503,9 @@
- allows for imports to be + + + allows for imports to be done based on a module or a derived revision of a module. The rev:revision-or-derived statement can specify either a revision date or a revision label. When importing by semver, the YANG semver revision label value MAY be used as an argument to @@ -488,26 +513,31 @@ latest revision label or has that label in its revision history can be used to satisfy the import requirement. For example: -
- +
+ import example-module { rev:revision-or-derived "3.0.0"; } - -
+ +
- Note: the import lookup does not stop +Note: the import lookup does not stop when a non-backward-compatible change is encountered. That is, if module B imports a module A at or derived from version 2.0.0, resolving that import will pass through a revision of module A with version 2.1.0_non_compatible in order to determine if the present instance of module A derives from 2.0.0. + +If an import by revision-or-derived cannot locate the specified revision-label in a given module's revision history, that import will fail. This is + noted in the case of version gaps. That is, if a module's history includes 1.0.0, 1.1.0, and 1.3.0, an import from revision-or-derived at 1.2.0 will be + unable to locate the specified revision entry and thus the import cannot be satisfied.
- This section and the IETF-specific sub-section below provides YANG semver-specific +This section and the IETF-specific sub-section below provides YANG semver-specific guidelines to consider when developing new YANG modules. As such this section - updates . + updates +. - Development of a brand new YANG module outside of the IETF that uses YANG semver as its +Development of a brand new YANG module outside of the IETF that uses YANG semver as its revision-label scheme SHOULD begin with a 0 for the MAJOR version component. This allows the module to disregard strict semver rules with respect to non-backwards-compatible changes @@ -520,20 +550,20 @@ (e.g., a module's revision label may transition from 0.3.0 to 1.0.0-beta.1 to indicate it is more mature and ready for testing). - When using pre-release notation, the format MUST include at least one alphabetic +When using pre-release notation, the format MUST include at least one alphabetic component and MUST end with a '.' and then one or more digits. These alphanumeric components will be used when deciding pre-release precedence. The following are examples of valid pre-release versions - - 1.0.0-alpha.1 - 1.0.0-alpha.3 - 2.1.0-beta.42 - 3.0.0-202007.rc.1 - - + +1.0.0-alpha.1 +1.0.0-alpha.3 +2.1.0-beta.42 +3.0.0-202007.rc.1 + + - When developing a new revision of an existing module using the YANG +When developing a new revision of an existing module using the YANG semver revision-label scheme, the intended target semver version MUST be used along with pre-release notation. For example, if a released module which has a current revision-label of 1.0.0 is being modified @@ -559,8 +589,8 @@ version might be 2.0.0-202005-alpha.1 if keeping the same year and month notation mentioned above). -
- - [TODO: Describe precedence considering there could be changes during development and parallel development tracks.] -
+[TODO: Describe precedence considering there could be changes during development and parallel development tracks.] +
-
- Net new module development within the IETF SHOULD begin with the 0 MAJOR number scheme as described above. +
+Net new module development within the IETF SHOULD begin with the 0 MAJOR number scheme as described above. When revising an existing IETF module, the revision-label MUST use the target (i.e., intended) MAJOR and MINOR version components with a 0 patch version component. If the intended ratified release will be non-backward-compatible with the current ratified release, the MINOR version component MUST be 0. - All IETF modules in development MUST use the whole document name as a pre-release version string, +All IETF modules in development MUST use the whole document name as a pre-release version string, including the current document revision. For example, if a module which is currently released at version 1.0.0 is being revised to include non-backwards-compatible changes in draft-user-netmod-foo, its @@ -593,26 +623,28 @@ draft name as a pre-release component helps to ensure uniqueness when there are perhaps multiple, parallel efforts creating the same module. - If a module is being revised and the original module never had a +If a module is being revised and the original module never had a revision-label (i.e., you wish to start using YANG semver in future module revisions), choose a semver value that makes the most sense based on the module's history. For example, if a module started - out in the pre-NMDA () world, and then had NMDA support added without + out in the pre-NMDA ( +) world, and then had NMDA support added without removing any legacy "state" branches -- and you are looking to add additional new features -- a sensible choice for the target YANG semver would be 1.2.0 (since 1.0.0 would have been the initial, pre-NMDA release, and 1.1.0 would have been the NMDA revision). - See for a detailed example of IETF pre-release versions. -
+See + for a detailed example of IETF pre-release versions. +
- This YANG module contains the typedef for the YANG semantic version. +This YANG module contains the typedef for the YANG semantic version. -
- - + + file "ietf-yang-semver@2019-09-06.yang" module ietf-yang-semver { yang-version 1.1; @@ -695,81 +727,149 @@ } ]]> - -
-
+ + +
- This document grew out of the YANG module versioning design team +This document grew out of the YANG module versioning design team that started after IETF 101. The design team consists of the following members whom have worked on the YANG versioning project: - - - Balazs Lengyel - Benoit Claise - Ebben Aries - Jason Sterne - Joe Clarke - Juergen Schoenwaelder - Mahesh Jethanandani - Michael (Wangzitao) - Qin Wu - Reshad Rahman - Rob Wilton - - - - The initial revision of this document was refactored and built - upon . - Discussons on the use of Semver for YANG versioning has been held - with authors of the OpenConfig YANG models based on their own . We would like thank both + + +Balazs Lengyel +Benoit Claise +Ebben Aries +Jason Sterne +Joe Clarke +Juergen Schoenwaelder +Mahesh Jethanandani +Michael (Wangzitao) +Qin Wu +Reshad Rahman +Rob Wilton + + + +The initial revision of this document was refactored and built + upon +. +Discussons on the use of Semver for YANG versioning has been held + with authors of the OpenConfig YANG models based on their own +. We would like thank both Anees Shaikh and Rob Shakir for their input into this problem space.
- The document does not define any new protocol or data model. There +The document does not define any new protocol or data model. There are no security impacts.
- None. +
+The following YANG module is requested to be registred in the + "IANA Module Names" registry: + + + +Name: ietf-yang-semver +XML Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-semver +Prefix: yangver +Reference: [RFCXXXX] + + +
+
+Note for IANA (to be removed by the RFC editor): Please check that the + registries and IANA YANG modules are referenced in the appropriate way. + +IANA is responsible for maintaining and versioning some YANG + modules, e.g., iana-if-types.yang + and + iana-routing-types.yang +. + +In addition to following the rules specified in the IANA + Considerations section of +, IANA maintained + YANG modules MUST also include a YANG Semver revision label for all + new revisions, as defined in +. + +The YANG Semver version associated with the new revision MUST + follow the rules defined in +. + +Note: For IANA maintained YANG modules that have already been + published, revision labels MUST be retrospectively applied to all + existing revisions when the next new revision is created, starting + at version "1.0.0" for the initial published revision, and then + incrementing according to the YANG Semver version rules specified in + +. + +Most changes to IANA maintained YANG modules are expected to be + backwards-compatible changes and classified as MINOR version + changes. The PATCH version may be incremented instead when only + editorial changes are made, and the MAJOR version would be + incremented if non-backwards-compatible major changes are made. + +Given that IANA maintained YANG modules are versioned with a + linear history, it is anticipated that it should not be necessary to + use the "_compatible" or "_non_compatible" modifiers to the + "Z_COMPAT" version element. +
- - - - + + + + - - - - - - Semantic Versioning for Openconfig Models - - - - - - - Semantic Versioning 2.0.0 - - - - + + + + + +Semantic Versioning for Openconfig Models + + + + + + +Semantic Versioning 2.0.0 + + + + + + +iana-if-type YANG Module + + + + + + +iana-routing-types YANG Module + + + +
- Assume a new YANG module is being developed in the netmod working group in the IETF. +Assume a new YANG module is being developed in the netmod working group in the IETF. Initially, this module is being developed in an individual internet draft, draft-jdoe-netmod-example-module. The following represents the initial version tree (i.e., value of revision-label) of the module as it's being initially developed. -
- Version lineage for initial module development: - +
+Version lineage for initial module development: + 0.0.1-draft-jdoe-netmod-example-module-00 | 0.1.0-draft-jdoe-netmod-example-module-01 @@ -777,46 +877,46 @@ 0.2.0-draft-jdoe-netmod-example-module-02 | 0.2.1-draft-jdoe-netmod-example-module-03 - -
+ +
- At this point, development stabilizes, and the workgroup adopts the draft. Thus now the draft becomes +At this point, development stabilizes, and the workgroup adopts the draft. Thus now the draft becomes draft-ietf-netmod-example-module. The initial pre-release lineage continues as follows. -
- Continued version lineage after adoption: +
+Continued version lineage after adoption: - + 1.0.0-draft-ietf-netmod-example-module-00 | 1.0.0-draft-ietf-netmod-example-module-01 | 1.0.0-draft-ietf-netmod-example-module-02 - +
- At this point, the draft is ratified and becomes RFC12345 and the YANG module version number becomes 1.0.0. +At this point, the draft is ratified and becomes RFC12345 and the YANG module version number becomes 1.0.0. - A time later, the module needs to be revised to add additional capabilities. Development will be done in a +A time later, the module needs to be revised to add additional capabilities. Development will be done in a backwards-compatible way. Two new individual drafts are proposed to go about adding the capabilities in different ways: draft-jdoe-netmod-exmod-enhancements and draft-jadoe-netmod-exmod-changes. These are initially developed in parallel with the following versions. -
- Parallel development for next module revision: +
+Parallel development for next module revision: - + 1.1.0-draft-jdoe-netmod-exmod-enhancements-00 || 1.1.0-draft-jadoe-netmod-exmod-changes-00 | | 1.1.0-draft-jdoe-netmod-exmod-enhancements-01 || 1.1.0-draft-jadoe-netmod-exmod-changes-01 - -
+ +
- At this point, the WG decides to merge some aspects of both and adopt the work in jadoe's draft +At this point, the WG decides to merge some aspects of both and adopt the work in jadoe's draft as draft-ietf-netmod-exmod-changes. A single version lineage continues. -
- +
+ 1.1.0-draft-ietf-netmod-exmod-changes-00 | 1.1.0-draft-ietf-netmod-exmod-changes-01 @@ -824,10 +924,10 @@ 1.1.0-draft-ietf-netmod-exmod-changes-02 | 1.1.0-draft-ietf-netmod-exmod-changes-03 - -
+ +
- The draft is ratified, and the new module version becomes 1.1.0. +The draft is ratified, and the new module version becomes 1.1.0.