YANG Semantic Versioning
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.
rwilton@cisco.com
reshad@yahoo.com
Ericsson
Magyar Tudosok Korutja
1117 Budapest
Hungary
+36-70-330-7909
balazs.lengyel@ericsson.com
Nokia
jason.sterne@nokia.com
Huawei
benoit.claise@huawei.com
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.
Introduction
puts forth a number of concepts relating
to modified rules for updating 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
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
rules for YANG artifacts
(i.e., YANG modules, YANG submodules, and 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.
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
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
are examples of YANG artifacts
for the purposes of this document.
- YANG Semver: A revision-label identifier that is consistent with the extended set of semantic versioning rules, based on
,
defined within this document.
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.
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,
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 when comparing YANG semantic versions, pre-release metadata MUST be used
during module and submodule development as specified in
. Both pre-release and build metadata are allowed in order
to support all 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 and submodules 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.
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
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
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
.
- 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
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.
Every YANG module and submodule versioned using the YANG semantic versioning
scheme specifies the module's or submodule's semantic version number as the argument
to the 'rev:revision-label' statement.
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 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'; where X, Y, and Z each represent non-negative
integers less than or equal to 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
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 PATCH "_compatible" or "_non_compatible" modifier.
-
'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
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. 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 indendation), 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.
- 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 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.
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 and 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:
- The including module has editorial changes
- The submodule with the schema definition removed has non-backwards-compatible changes
- 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).
Examples for YANG semantic versions
The following diagram and explanation illustrate how YANG semantic versions work.
Example YANG semantic versions for an example artifact:
1.1.1_compatible -> 1.1.2_non_compatible
| |
| 1.2.0 -> 1.2.1_non_compatible -> 1.2.2_non_compatible
| |
| 1.3.0 -> 1.3.1
|
2.0.0
|
3.0.0
\
3.1.0
]]>
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 of when the revisions were published,
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)
- 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 are 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
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.
YANG Semantic Version Update Rules
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.
The following four rules specify the RECOMMENDED, and REQUIRED minimum, update to a YANG semantic version number:
- 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.
-
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 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.
- "X.Y.Z_compatible" - the artifact version SHOULD be updated to
"X.Y.Z+1_compatible".
- "X.Y.Z_non_compatible" - the artifact version SHOULD be updated to
"X.Y.Z+1_non_compatible".
-
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 SHOULD be updated to "X.Y.Z+1"
- "X.Y.Z_compatible" - the artifact version SHOULD be updated to
"X.Y.Z+1_compatible".
- "X.Y.Z_non_compatible" - the artifact version SHOULD be updated to
"X.Y.Z+1_non_compatible".
- 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
for
more details on using this notation during module and submodule development.
- Additional pre-release rules for modules that have had at least one release are specified in
.
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:
- 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.
- 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
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.,
, also plays an important role for comparing YANG artifacts and calculating the likely impact from changes.
defines the "rev:nbc-changes" 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:nbc-changes" 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:nbc-changes" statement would be present.
Examples of the YANG Semver Label
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.
Example of Package Using YANG Semver
Below is an example YANG package that uses the semver revision label based on
the rules defined in this document.
Import Module by Semantic Version
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:
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.
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
.
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
When developing a new revision of an existing module or submodule 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 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).
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
semver 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.
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.
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.
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
.
For example, if a module or submodule started 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.
YANG Module
This YANG module contains the typedef for the YANG semantic version and the identity to signal its use.
WG List:
Author: Joe Clarke
Author: Benoit Claise
Author: Reshad Rahman
Author: Robert Wilton
Author: Balazs Lengyel
Author: Jason Sterne
";
description
"This module provides type and grouping definitions for YANG
packages.
Copyright (c) 2021 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 Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
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 2021-10-20 {
rev:revision-label "1.0.0-draft-ietf-netmod-yang-semver-04";
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 string {
pattern '[0-9]+[.][0-9]+[.][0-9]+(_(non_)?compatible)?(-[A-Za-z0-9.-]+)?([+][A-Za-z0-9.-]+)?';
}
description
"Represents a YANG semantic version number. The rules governing the
use of this revision label scheme are defined in the reference for
this typedef.";
reference
"RFC XXXX: YANG Semantic Versioning.";
}
}
]]>
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
- 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
. We would like the thank Kevin D'Souza for his initial work in this problem space.
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.
Security Considerations
The document does not define any new protocol or data model. There
are no security impacts.
IANA Considerations
YANG Module Registrations
This document requests IANA to register a URI in the "IETF XML Registry"
. 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 registred in the "IANA
Module Names"
. Following the format in RFC 6020,
the following registrations are requested:
The ietf-yang-semver module:
- Name: ietf-yang-semver
- XML Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-semver
- Prefix: yangver
- Reference: [RFCXXXX]
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
and
iana-routing-types.yang
.
In addition to following the rules specified in the IANA
Considerations section of
, IANA maintained
YANG modules and submodules 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 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
.
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.
References
Normative References
Informative References
Semantic Versioning for Openconfig Models
Semantic Versioning 2.0.0 (text from June 19, 2020)
iana-if-type YANG Module
iana-routing-types YANG Module
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:
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:
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
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:
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.
The draft is ratified, and the new module version becomes 1.1.0.