YANG Semantic Versioning
draft-ietf-netmod-yang-semver-08
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Joe Clarke , Robert Wilton , Reshad Rahman , Balázs Lengyel , Jason Sterne , Benoît Claise | ||
| Last updated | 2022-10-24 | ||
| Replaces | draft-verdt-netmod-yang-semver | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Waiting for WG Chair Go-Ahead | |
| Document shepherd | Lou Berger | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | lberger@labn.net |
draft-ietf-netmod-yang-semver-08
Network Working Group J. Clarke, Ed.
Internet-Draft R. Wilton, Ed.
Updates: 8407 (if approved) Cisco Systems, Inc.
Intended status: Standards Track R. Rahman
Expires: 27 April 2023
B. Lengyel
Ericsson
J. Sterne
Nokia
B. Claise
Huawei
24 October 2022
YANG Semantic Versioning
draft-ietf-netmod-yang-semver-08
Abstract
This document specifies a scheme and guidelines for applying an
extended set of semantic versioning rules to revisions of YANG
artifacts (e.g., modules and packages). Additionally, this document
defines an RFCAAAA-compliant revision-label-scheme for this YANG
semantic versioning scheme.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
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 27 April 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Clarke, et al. Expires 27 April 2023 [Page 1]
Internet-Draft YANG Semver October 2022
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
3. YANG Semantic Versioning . . . . . . . . . . . . . . . . . . 4
3.1. Relationship Between SemVer and YANG Semver . . . . . . . 4
3.2. YANG Semver Pattern . . . . . . . . . . . . . . . . . . . 4
3.3. Semantic Versioning Scheme for YANG Artifacts . . . . . . 5
3.3.1. Branching Limitations with YANG Semver . . . . . . . 7
3.3.2. YANG Semver with submodules . . . . . . . . . . . . . 8
3.3.3. Examples for YANG semantic versions . . . . . . . . . 8
3.4. YANG Semantic Version Update Rules . . . . . . . . . . . 10
3.5. Examples of the YANG Semver Label . . . . . . . . . . . . 12
3.5.1. Example Module Using YANG Semver . . . . . . . . . . 12
3.5.2. Example of Package Using YANG Semver . . . . . . . . 14
4. Import Module by Semantic Version . . . . . . . . . . . . . . 14
5. Guidelines for Using Semver During Module Development . . . . 15
5.1. Pre-release Version Precedence . . . . . . . . . . . . . 16
5.2. YANG Semver in IETF Modules . . . . . . . . . . . . . . . 17
5.2.1. Guidelines for IETF Module Development . . . . . . . 17
5.2.2. Guidelines for Published IETF Modules . . . . . . . . 17
6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9.1. YANG Module Registrations . . . . . . . . . . . . . . . . 20
9.2. Guidance for YANG Semver in IANA maintained YANG modules
and submodules . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Example IETF Module Development . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
Clarke, et al. Expires 27 April 2023 [Page 2]
Internet-Draft YANG Semver October 2022
1. Introduction
[I-D.ietf-netmod-yang-module-versioning] puts forth a number of
concepts relating to modified rules for updating YANG modules and
submodules, a means to signal when a new revision of a module or
submodule has non-backwards-compatible (NBC) changes compared to its
previous revision, and a scheme that uses the revision history as a
lineage for determining from where a specific revision of a YANG
module or submodule is derived. Additionally, section 3.4 of
[I-D.ietf-netmod-yang-module-versioning] defines a revision-label
which can be used as an alias to provide additional context or as a
meaningful label to refer to a specific revision.
This document defines a revision-label scheme that uses extended
semantic versioning rules [SemVer] for YANG artifacts (i.e., YANG
modules, YANG submodules, and YANG packages
[I-D.ietf-netmod-yang-packages] ) as well as the revision label
definition for using this scheme. The goal being to add a human
readable revision label that provides compatibility information for
the YANG artifact without needing to compare or parse its body. The
label and rules defined herein represent the RECOMMENDED revision
label scheme for IETF YANG artifacts.
Note that a specific revision of the SemVer 2.0.0 specification is
referenced here (from June 19, 2020) to provide an immutable version.
This is because the 2.0.0 version of the specification has changed
over time without any change to the semantic version itself. In some
cases the text has changed in non-backwards-compatible ways.
2. Terminology and Conventions
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Additionally, this document uses the following terminology:
* YANG artifact: YANG modules, YANG submodules, and YANG packages
[I-D.ietf-netmod-yang-packages] are examples of YANG artifacts for
the purposes of this document.
* SemVer: A version string that corresponds to the rules defined in
[SemVer]. This specific camel-case notation is the one used by
the SemVer 2.0.0 website and used within this document to
distinguish between YANG Semver.
Clarke, et al. Expires 27 April 2023 [Page 3]
Internet-Draft YANG Semver October 2022
* YANG Semver: A revision-label identifier that is consistent with
the extended set of semantic versioning rules, based on [SemVer] ,
defined within this document.
3. YANG Semantic Versioning
This section defines YANG Semantic Versioning, explains how it is
used with YANG artifacts, and describes the rules associated with
changing an artifact's semantic version when its contents are
updated.
3.1. Relationship Between SemVer and YANG Semver
[SemVer] is completely compatible with YANG Semver in that a SemVer
semantic version number is legal according to the YANG Semver rules
(though the inverse is not necessarily true). YANG Semver is a
superset of the SemVer rules, and allow for limited branching within
YANG artifacts. If no branching occurs within a YANG artifact (i.e.,
you do not use the compatibility modifiers described below), the YANG
Semver version label will appear as a SemVer version number.
3.2. YANG Semver Pattern
YANG artifacts that employ semantic versioning as defined in this
document MUST use a version string (e.g., in revision-label or as a
package version) that corresponds to the following pattern:
'X.Y.Z_COMPAT'. Where:
* X, Y and Z are mandatory non-negative integers that are each less
than or equal to 2147483647 (i.e., the maximum signed 32-bit
integer value) and MUST NOT contain leading zeroes,
* The '.' is a literal period (ASCII character 0x2e),
* The '_' is an optional single literal underscore (ASCII character
0x5f) and MUST only be present if the following COMPAT element is
included,
* COMPAT, if 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 YANG 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 when comparing YANG semantic versions, pre-
Clarke, et al. Expires 27 April 2023 [Page 4]
Internet-Draft YANG Semver October 2022
release metadata MUST be used during module and submodule development
as specified in Section 5 . Both pre-release and build metadata are
allowed in order to support all the [SemVer] rules. Thus, a version
lineage that follows strict [SemVer] rules is allowed for a YANG
artifact.
To signal the use of this versioning scheme, modules and submodules
MUST set the revision-label-scheme extension, as defined in
[I-D.ietf-netmod-yang-module-versioning] , 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.
3.3. Semantic Versioning Scheme for YANG Artifacts
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 [SemVer]
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 [SemVer] versioning scheme, the YANG semantic
versioning scheme supports 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
[I-D.ietf-netmod-yang-module-versioning] .
* YANG artifacts that follow the [SemVer] 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 of the
artifact only, then the version numbers used by the YANG semantic
versioning scheme are exactly the same as those defined by the
[SemVer] versioning scheme.
Every YANG module and submodule versioned using the YANG semantic
versioning scheme specifies the module's or submodule's semantic
version as the argument to the 'rev:revision-label' statement.
Clarke, et al. Expires 27 April 2023 [Page 5]
Internet-Draft YANG Semver October 2022
Because the rules put forth in
[I-D.ietf-netmod-yang-module-versioning] 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 or submodule may have been produced
before this scheme was available.
YANG packages that make use of this YANG Semver will reflect that in
the package metadata.
As stated above, the YANG semantic version is expressed as a string
of the form: 'X.Y.Z_COMPAT'.
* '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
indicate changes that are backwards-compatible to versions with
the same MAJOR version number, but a lower MINOR version number
and no "_compatible" or "_non_compatible" modifier.
* 'Z' is the PATCH version. Changes in the PATCH version number can
indicate an editorial change to the YANG artifact. In conjunction
with the '_COMPAT' modifier (see below) changes to 'Z' may
indicate a more substantive module 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. Some examples include correcting a spelling
mistake in the description of a leaf within a YANG module or
submodule, non-significant whitespace changes (e.g., realigning
description statements or changing indentation), or changes to
YANG comments. 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.
* '_COMPAT' is an additional modifier, unique to YANG Semver (i.e.,
not valid in [SemVer]), that indicates 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
editorial change.
Clarke, et al. Expires 27 April 2023 [Page 6]
Internet-Draft YANG Semver October 2022
- 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 '_COMPAT' modifier string is "sticky". Once a revision of a
module has a modifier in the revision label, then all descendants of
that revision with the same X.Y version digits will also have a
modifier. The modifier can change from "_compatible" to
"_non_compatible" in a descendant revision, but the modifier MUST NOT
change from "_non_compatible" to "_compatible" and MUST NOT be
removed. The persistence of the "_non_compatible" modifier ensures
that comparisons of revision labels do not give the false impression
of compatibility between two potentially non-compatible revisions.
If "_non_compatible" was removed, for example between revisions
"3.3.2_non_compatible" and "3.3.3" (where "3.3.3" was simply an
editorial change), then comparing revision labels of "3.3.3" back to
an ancestor "3.0.0" would look like they are backwards compatible
when they are not (since "3.3.2_non_compatible" was in the chain of
ancestors and introduced a non-backwards-compatible change).
The YANG artifact name and YANG semantic version 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
but different content (and in the case of modules and submodules,
different revision dates).
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.
3.3.1. Branching Limitations with YANG Semver
YANG artifacts that use the YANG Semver revision-label scheme MUST
ensure that two artifacts with the same MAJOR version number and no
_compatible or _non_compatible modifiers are backwards compatible.
Therefore, certain branching schemes cannot be used with YANG Semver.
For example, the following branched parent-child module relationship
using the following YANG Semver revision labels is not supported:
Clarke, et al. Expires 27 April 2023 [Page 7]
Internet-Draft YANG Semver October 2022
3.5.0 -- 3.6.0 (add leaf foo)
|
|
3.20.0 (added leaf bar)
In this case, given only the revision labels 3.6.0 and 3.20.0 without
any parent-child relationship information, one would assume that
3.20.0 is backwards compatible with 3.6.0. But in the illegal
example above, 3.20.0 is not backwards compatible with 3.6.0 since
3.20.0 does not contain the leaf foo.
Note that this type of branched parent-child relationship, where two
revisions have different backwards compatible changes based on the
same parent, is allowed in [I-D.ietf-netmod-yang-module-versioning].
3.3.2. YANG Semver with submodules
YANG Semver MAY be used to version submodules. Submodule version are
separate of any version on the including module, but if a submodule
has changed, then the version of the including module MUST also be
updated.
The rules for determining the version change of a submodule are the
same as those defined in Section 3.2 and Section 3.3 as applied to
YANG modules, except they only apply to the part of the module schema
defined within the submodule's file.
One interesting case is moving definitions from one submodule to
another in a way that does not change the resultant schema of the
including module. In this case:
1. The including module has editorial changes
2. The submodule with the schema definition removed has non-
backwards-compatible changes
3. The submodule with the schema definitions added has backwards-
compatible changes
Note that the meaning of a submodule may change drastically despite
having no changes in content or revision due to changes in other
submodules belonging to the same module (e.g. groupings and typedefs
declared in one submodule and used in another).
3.3.3. Examples for YANG semantic versions
The following diagram and explanation illustrate how YANG semantic
versions work.
Clarke, et al. Expires 27 April 2023 [Page 8]
Internet-Draft YANG Semver October 2022
YANG Semantic versions for an example module:
0.1.0
|
0.2.0
|
1.0.0
|
1.1.0 -> 1.1.1_compatible -> 1.1.2_non_compatible
|
1.2.0 -> 1.2.1_non_compatible -> 1.2.2_non_compatible
| \
2.0.0 \
| \--> 1.3.0 -> 1.3.1_non_compatible
3.0.0 |
| 1.4.0
3.1.0
The tree diagram above illustrates how the version history might
evolve for an example module. The tree diagram only shows the
parent/child ancestry relationships between the revisions. It does
not describe the chronology of the revisions (i.e. when in time each
revision was published relative to the other revisions).
The following description lists an example of what the chronological
order of the revisions could look like, from oldest revision to
newest:
0.1.0 - first pre-release module version
0.2.0 - second pre-release 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)
2.0.0 - change existing model for performance reasons, e.g. re-key
list (NBC)
1.3.0 - improve existing functionality, added leaf "foo-64" (BC)
1.1.1_compatible - backport "foo-64" leaf to 1.1.x to avoid
implementing "baz" from 1.2.0. This revision was created after
1.2.0 otherwise it may have been released as 1.2.0. (BC)
Clarke, et al. Expires 27 April 2023 [Page 9]
Internet-Draft YANG Semver October 2022
3.0.0 - NBC bugfix, rename "baz" to "bar"; also add new BC leaf
"wibble"; (NBC)
1.3.1_non_compatible - backport NBC fix, rename "baz" to "bar"
(NBC)
1.2.1_non_compatible - backport NBC fix, rename "baz" to "bar"
(NBC)
1.1.2_non_compatible - NBC point bug fix, not required in 2.0.0
due to model changes (NBC)
1.4.0 - introduce new leaf "ghoti" (BC)
3.1.0 - introduce new leaf "wobble" (BC)
1.2.2_non_compatible - backport "wibble". This is a BC change but
"non_compatible" modifier is sticky. (BC)
The partial ancestry relationships based on the semantic versioning
numbers are as follows:
1.0.0 < 1.1.0 < 1.2.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
1.0.0 < 1.1.0 < 1.2.0 < 1.3.0 < 1.3.1_non_compatible
1.0.0 < 1.1.0 < 1.2.0 < 1.3.0 < 1.4.0
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 does not indicate ancestry. The
module definition in "2.0.0", for example, does not contain all the
contents of "1.3.0". Version "2.0.0" is not derived from "1.3.0".
3.4. YANG Semantic Version Update Rules
When a new revision of an artifact is produced, then the following
rules define how the YANG semantic version for the new artifact
revision is calculated, based on the changes between the two artifact
revisions, and the YANG semantic version of the base artifact
revision from which the changes are derived.
Clarke, et al. Expires 27 April 2023 [Page 10]
Internet-Draft YANG Semver October 2022
The following four rules specify the RECOMMENDED, and REQUIRED
minimum, update to a YANG semantic version:
1. If an artifact is being updated in a non-backwards-compatible
way, then the artifact version
"X.Y.Z[_compatible|_non_compatible]" SHOULD be updated to
"X+1.0.0" unless that version has already been used for this
artifact but with different content, in which case the artifact
version "X.Y.Z+1_non_compatible" SHOULD be used instead.
2. 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:
i "X.Y.Z" - the artifact version SHOULD be updated to
"X.Y+1.0", unless that version has already been used for
this artifact but with different content, when the artifact
version SHOULD be updated to "X.Y.Z+1_compatible" instead.
ii "X.Y.Z_compatible" - the artifact version SHOULD be updated
to "X.Y.Z+1_compatible".
iii "X.Y.Z_non_compatible" - the artifact version SHOULD be
updated to "X.Y.Z+1_non_compatible".
3. If an artifact is being updated in an editorial way, then the
next version number depends on the format of the current version
number:
i "X.Y.Z" - the artifact version SHOULD be updated to
"X.Y.Z+1"
ii "X.Y.Z_compatible" - the artifact version SHOULD be updated
to "X.Y.Z+1_compatible".
iii "X.Y.Z_non_compatible" - the artifact version SHOULD be
updated to "X.Y.Z+1_non_compatible".
4. YANG artifact semantic version numbers beginning with 0, i.e.,
"0.X.Y", are regarded as pre-release 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 Section 5 for more details on using this notation during
module and submodule development.
5. Additional pre-release rules for modules that have had at least
one release are specified in Section 5 .
Clarke, et al. Expires 27 April 2023 [Page 11]
Internet-Draft YANG Semver October 2022
Although artifacts SHOULD be updated according to the rules above,
which specify the recommended (and minimum required) update to the
version number, the following rules MAY be applied when choosing a
new version number:
1. An artifact author MAY update the version number with a more
significant update than described by the rules above. For
example, an artifact could be given a new MAJOR version number
(i.e., X+1.0.0), even though no non-backwards-compatible changes
have occurred, or an artifact could be given a new MINOR version
number (i.e., X.Y+1.0) even if the changes were only editorial.
2. An artifact author MAY skip version numbers. That is, an
artifact's revision history could be 1.0.0, 1.1.0, and 1.3.0
where 1.2.0 is skipped. Note that skipping versions has an
impact when importing modules by revision-or-derived. See
Section 4 for more details on importing modules with revision-
label version gaps.
Although YANG Semver always indicates when a non-backwards-
compatible, or backwards-compatible change may have occurred to a
YANG artifact, it does not guarantee that such a change has occurred,
or that consumers of that YANG artifact will be impacted by the
change. Hence, tooling, e.g.,
[I-D.ietf-netmod-yang-schema-comparison] , also plays an important
role for comparing YANG artifacts and calculating the likely impact
from changes.
[I-D.ietf-netmod-yang-module-versioning] defines the "rev:non-
backwards-compatible" extension statement to indicate where non-
backwards-compatible changes have occurred in the module revision
history. If a revision entry in a module's revision history includes
the "rev:non-backwards-compatible" statement then that MUST be
reflected in any YANG semantic version associated with that revision.
However, the reverse does not necessarily hold, i.e., if the MAJOR
version has been incremented it does not necessarily mean that a
"rev:non-backwards-compatible" statement would be present.
3.5. Examples of the YANG Semver Label
3.5.1. Example Module Using YANG Semver
Below is a sample YANG module that uses the YANG Semver revision-
label based on the rules defined in this document.
Clarke, et al. Expires 27 April 2023 [Page 12]
Internet-Draft YANG Semver October 2022
module example-versioned-module {
yang-version 1.1;
namespace "urn:example:versioned:module";
prefix "exvermod";
rev:revision-label-scheme "ysver:yang-semver";
import ietf-yang-revisions { prefix "rev"; }
import ietf-yang-semver { prefix "ysver"; }
description
"to be completed";
revision 2017-08-30 {
description "Backport 'wibble' leaf";
rev:revision-label 1.2.2_non_compatible;
}
revision 2017-07-30 {
description "Rename 'baz' to 'bar'";
rev:revision-label 1.2.1_non_compatible;
rev:non-backwards-compatible;
}
revision 2017-04-20 {
description "Add new functionality, leaf 'baz'";
rev:revision-label 1.2.0;
}
revision 2017-04-03 {
description "Add new functionality, leaf 'foo'";
rev:revision-label 1.1.0;
}
revision 2017-02-07 {
description "First release version.";
rev:revision-label 1.0.0;
}
// Note: YANG Semver rules do not apply to 0.X.Y labels.
// The following pre-release revision statements would not
// appear in any final published version of a module. They
// are removed when the final version is published.
// During the pre-release phase of development, only a
// single one of these revision statements would appear
// revision 2017-01-30 {
// description "NBC changes to initial revision";
// rev:revision-label 0.2.0;
Clarke, et al. Expires 27 April 2023 [Page 13]
Internet-Draft YANG Semver October 2022
// rev:non-backwards-compatible; // optional
// // (theoretically no
// // 'previous released version')
// }
// revision 2017-01-26 {
// description "Initial module version";
// rev:revision-label 0.1.0;
// }
//YANG module definition starts here
}
3.5.2. Example of Package Using YANG Semver
Below is an example YANG package that uses the YANG Semver revision
label based on the rules defined in this document.
{
"ietf-yang-instance-data:instance-data-set": {
"name": "example-yang-pkg",
"target-ptr": "TBD",
"timestamp": "2018-09-06T17:00:00Z",
"description": "Example IETF package definition",
"content-data": {
"ietf-yang-package:yang-package": {
"name": "example-yang-pkg",
"version": "1.3.1",
...
}
4. Import Module by Semantic Version
[I-D.ietf-netmod-yang-module-versioning] 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. The YANG Semver revision-label value can be
used as the argument to rev:revision-or-derived . When used as such,
any module that contains exactly the same YANG semantic version in
its revision history may be used to satisfy the import requirement.
For example:
import example-module {
rev:revision-or-derived 3.0.0;
}
Clarke, et al. Expires 27 April 2023 [Page 14]
Internet-Draft YANG Semver October 2022
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.
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] .
Development of a brand new YANG module or submodule 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 or
submodule to disregard strict SemVer rules with respect to non-
backwards-compatible changes during its initial development.
However, module or submodule developers MAY choose to use the SemVer
pre-release syntax instead with a 1 for the MAJOR version component.
For example, an initial module or submodule revision-label might be
either 0.0.1 or 1.0.0-alpha.1. If the authors choose to use the 0
MAJOR version component scheme, they MAY switch to the pre-release
scheme with a MAJOR version component of 1 when the module or
submodule is nearing initial release (e.g., a module's or submodule'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 component and MUST end with a '.' or '-' 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
Clarke, et al. Expires 27 April 2023 [Page 15]
Internet-Draft YANG Semver October 2022
When developing a new revision of an existing module or submodule
using the YANG Semver revision-label scheme, the intended target
semantic version MUST be used along with pre-release notation. For
example, if a released module or submodule which has a current
revision-label of 1.0.0 is being modified with the intent to make
non-backwards-compatible changes, the first 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 or submodule MUST have a unique 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
development began (e.g., 2.0.0-201907-alpha.1). As a module or
submodule undergoes development, it is possible that the original
intent changes. For example, a 1.0.0 version of a module or
submodule that was destined to become 2.0.0 after a development cycle
may have had a scope change such that the final version has no non-
backwards-compatible changes and becomes 1.1.0 instead. This change
is acceptable to make during the development phase so long as pre-
release notation is present in both versions (e.g., 2.0.0-alpha.3
becomes 1.1.0-alpha.4). However, on the next development cycle
(after 1.1.0 is released), if again the new target release is 2.0.0,
new pre-release components must be used such that every revision-
label for a given module or submodule MUST be unique throughout its
entire lifecycle (e.g., the first pre-release version might be
2.0.0-202005-alpha.1 if keeping the same year and month notation
mentioned above).
5.1. Pre-release Version Precedence
As a module or submodule is developed, the scope of the work may
change. That is, while a ratified module or submodule with revision-
label 1.0.0 is initially intended to become 2.0.0 in its next
ratified version, the scope of work may change such that the final
version is 1.1.0. During the development cycle, the pre-release
versions could move from 2.0.0-some-pre-release-tag to 1.1.0-some-
pre-release-tag. This downwards changing of version numbers makes it
difficult to evaluate semantic version rules between pre-release
versions. However, taken independently, each pre-release version can
be compared to the previously ratified version (e.g., 1.1.0-some-pre-
release-tag and 2.0.0-some-pre-release-tag can each be compared to
1.0.0). Module and submodule developers SHOULD maintain only one
revision statement in a pre-released module or submodule that
reflects the latest revision. IETF authors MAY choose to include an
appendix in the associated draft to track overall changes to the
module or submodule.
Clarke, et al. Expires 27 April 2023 [Page 16]
Internet-Draft YANG Semver October 2022
5.2. YANG Semver in IETF Modules
All published IETF modules and submodules MUST use YANG semantic
versions for their revision-labels.
Development of a new module or submodule within the IETF SHOULD begin
with the 0 MAJOR number scheme as described above. When revising an
existing IETF module or submodule, 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.
5.2.1. Guidelines for IETF Module Development
All IETF modules and submodules in development MUST use the whole
document name as a pre-release version string, including the current
document revision. For example, if a module or submodule which is
currently released at version 1.0.0 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 (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 or submodule. Even when using the 0
MAJOR version for initial module or submodule development (where
MINOR and PATCH can change), appending the draft name as a pre-
release component helps to ensure uniqueness when there are perhaps
multiple, parallel efforts creating the same module or submodule.
Some draft revisions may not include an update to the YANG modules or
submodules contained in the draft. In that case, those modules or
submodules that are not updated do not not require a change to their
versions. Updates to the YANG Semver version MUST only be done when
the revision of the module changes.
See Appendix A for a detailed example of IETF pre-release versions.
5.2.2. Guidelines for Published IETF Modules
For IETF YANG modules and submodules that have already been
published, revision-labels MUST be retroactively 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.4 . For example, if a module or submodule started out 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
Clarke, et al. Expires 27 April 2023 [Page 17]
Internet-Draft YANG Semver October 2022
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).
6. YANG Module
This YANG module contains the typedef for the YANG semantic version
and the identity to signal its use.
<CODE BEGINS> file "ietf-yang-semver@2022-09-13.yang"
module ietf-yang-semver {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-semver";
prefix ysver;
rev:revision-label-scheme "yang-semver";
import ietf-yang-revisions {
prefix rev;
}
organization
"IETF NETMOD (Network Modeling) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
Author: Joe Clarke
<mailto:jclarke@cisco.com>
Author: Robert Wilton
<mailto:rwilton@cisco.com>
Author: Reshad Rahman
<mailto:reshad@yahoo.com>
Author: Balazs Lengyel
<mailto:balazs.lengyel@ericsson.com>
Author: Jason Sterne
<mailto:jason.sterne@nokia.com>
Author: Benoit Claise
<mailto:benoit.claise@huawei.com>";
description
"This module provides type and grouping definitions for YANG
packages.
Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved.
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 Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Clarke, et al. Expires 27 April 2023 [Page 18]
Internet-Draft YANG Semver October 2022
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
// 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
// note.
// RFC Ed. update the rev:revision-label to "1.0.0".
revision 2022-09-13 {
rev:revision-label "1.0.0-draft-ietf-netmod-yang-semver-08";
description
"Initial revision";
reference
"RFC XXXX: YANG Semantic Versioning.";
}
/*
* Identities
*/
identity yang-semver {
base rev:revision-label-scheme-base;
description
"The revision-label scheme corresponds to the YANG Semver
scheme which is defined by the pattern in the 'version'
typedef below. The rules governing this revision-label
scheme are defined in the reference for this identity.";
reference
"RFC XXXX: YANG Semantic Versioning.";
}
/*
* Typedefs
*/
typedef version {
type rev:revision-label {
pattern '[0-9]+[.][0-9]+[.][0-9]+(_(non_)?compatible)?'
+ '(-[A-Za-z0-9.-]+[.-][0-9]+)?([+][A-Za-z0-9.-]+)?';
}
description
"Represents a YANG semantic version. The rules governing the
use of this revision label scheme are defined in the
reference for this typedef.";
Clarke, et al. Expires 27 April 2023 [Page 19]
Internet-Draft YANG Semver October 2022
reference
"RFC XXXX: YANG Semantic Versioning.";
}
}
<CODE ENDS>
7. Contributors
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, Bo Wu, Ebben Aries, Jan Lindblad, Jason
Sterne, Joe Clarke, Juergen Schoenwaelder, Mahesh Jethanandani,
Michael (Wangzitao), Qin Wu, Reshad Rahman, and Rob Wilton.
The initial revision of this document was refactored and built upon
[I-D.clacla-netmod-yang-model-update] . We would like the thank
Kevin D'Souza for his initial work in this problem space.
Discussions 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
Shakir for their input into this problem space.
8. Security Considerations
The document does not define any new protocol or data model. There
are no security impacts.
9. IANA Considerations
9.1. YANG Module Registrations
This document requests IANA to register a URI in the "IETF XML
Registry" [RFC3688] . Following the format in RFC 3688, the
following registration is requested.
URI: urn:ietf:params:xml:ns:yang:ietf-yang-semver
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
The following YANG module is requested to be registered in the "IANA
Module Names" [RFC6020] . Following the format in RFC 6020, the
following registrations are requested:
The ietf-yang-semver module:
Clarke, et al. Expires 27 April 2023 [Page 20]
Internet-Draft YANG Semver October 2022
Name: ietf-yang-semver
XML Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-semver
Prefix: ysver
Reference: [RFCXXXX]
9.2. Guidance for YANG Semver in IANA maintained YANG modules and
submodules
Note for IANA (to be removed by the RFC editor): Please check that
the registries and IANA YANG modules and submodules are referenced in
the appropriate way.
IANA is responsible for maintaining and versioning some YANG modules
and submodules, 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 and submodules 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.4 .
Note: For IANA maintained YANG modules and submodules that have
already been published, revision labels MUST be retroactively 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 rules specified in
Section 3.4 .
Most changes to IANA maintained YANG modules and submodules 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 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.
10. References
Clarke, et al. Expires 27 April 2023 [Page 21]
Internet-Draft YANG Semver October 2022
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of
Documents Containing YANG Data Models", BCP 216, RFC 8407,
DOI 10.17487/RFC8407, October 2018,
<https://www.rfc-editor.org/info/rfc8407>.
[I-D.ietf-netmod-yang-module-versioning]
Wilton, R., Rahman, R., Lengyel, B., Clarke, J., and J.
Sterne, "Updated YANG Module Revision Handling", Work in
Progress, Internet-Draft, draft-ietf-netmod-yang-module-
versioning-06, 10 July 2022,
<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
module-versioning-06.txt>.
10.2. Informative References
[I-D.clacla-netmod-yang-model-update]
Claise, B., Clarke, J., Lengyel, B., and K. D'Souza, "New
YANG Module Update Procedure", Work in Progress, Internet-
Draft, draft-clacla-netmod-yang-model-update-06, 2 July
2018, <https://www.ietf.org/archive/id/draft-clacla-
netmod-yang-model-update-06.txt>.
[I-D.ietf-netmod-yang-packages]
Wilton, R., Rahman, R., Clarke, J., Sterne, J., and B. Wu,
"YANG Packages", Work in Progress, Internet-Draft, draft-
ietf-netmod-yang-packages-03, 4 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
packages-03.txt>.
Clarke, et al. Expires 27 April 2023 [Page 22]
Internet-Draft YANG Semver October 2022
[I-D.ietf-netmod-yang-schema-comparison]
Wilton, R., "YANG Schema Comparison", Work in Progress,
Internet-Draft, draft-ietf-netmod-yang-schema-comparison-
01, 2 November 2020, <https://www.ietf.org/archive/id/
draft-ietf-netmod-yang-schema-comparison-01.txt>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[openconfigsemver]
"Semantic Versioning for Openconfig Models",
<http://www.openconfig.net/docs/semver/>.
[SemVer] "Semantic Versioning 2.0.0 (text from June 19, 2020)",
<https://github.com/semver/semver/
blob/8b2e8eec394948632957639dfa99fc7ec6286911/semver.md>.
[IfTypeYang]
"iana-if-type YANG Module",
<https://www.iana.org/assignments/iana-if-type/iana-if-
type.xhtml>.
[RoutingTypesYang]
"iana-routing-types YANG Module",
<https://www.iana.org/assignments/iana-routing-types/iana-
routing-types.xhtml>.
Appendix A. Example IETF Module Development
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:
0.0.1-draft-jdoe-netmod-example-module-00
|
0.1.0-draft-jdoe-netmod-example-module-01
|
0.2.0-draft-jdoe-netmod-example-module-02
|
0.2.1-draft-jdoe-netmod-example-module-03
Clarke, et al. Expires 27 April 2023 [Page 23]
Internet-Draft YANG Semver October 2022
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:
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 becomes 1.0.0.
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-asmith-netmod-exmod-changes. These are initially developed
in parallel with the following versions.
Parallel development for next module revision (track 1):
1.1.0-draft-jdoe-netmod-exmod-enhancements-00
|
1.1.0-draft-jdoe-netmod-exmod-enhancements-01
In parallel with (track 2):
1.1.0-draft-asmith-netmod-exmod-changes-00
|
1.1.0-draft-asmith-netmod-exmod-changes-01
At this point, the WG decides to merge some aspects of both and adopt
the work in asmith'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
|
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.
Clarke, et al. Expires 27 April 2023 [Page 24]
Internet-Draft YANG Semver October 2022
Authors' Addresses
Joe Clarke (editor)
Cisco Systems, Inc.
7200-12 Kit Creek Rd
Research Triangle Park, North Carolina
United States of America
Phone: +1-919-392-2867
Email: jclarke@cisco.com
Robert Wilton (editor)
Cisco Systems, Inc.
Email: rwilton@cisco.com
Reshad Rahman
Email: reshad@yahoo.com
Balazs Lengyel
Ericsson
1117 Budapest
Magyar Tudosok Korutja
Hungary
Phone: +36-70-330-7909
Email: balazs.lengyel@ericsson.com
Jason Sterne
Nokia
Email: jason.sterne@nokia.com
Benoit Claise
Huawei
Email: benoit.claise@huawei.com
Clarke, et al. Expires 27 April 2023 [Page 25]