This YANG module defines semantic version for Cisco defined YANG models. Copyright (c) 2019 by Cisco Systems, Inc. All rights re...
Version: 2019-03-20
module cisco-semver { yang-version 1; namespace "http://cisco.com/ns/yang/cisco-semver"; prefix cisco-semver; organization "Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 USA"; contact "Mailing list: <cs-yang@cisco.com>"; description "This YANG module defines semantic version for Cisco defined YANG models. Copyright (c) 2019 by Cisco Systems, Inc. All rights reserved."; revision "2019-03-20" { description "Initial Version."; reference "draft-verdt-netmod-yang-solutions-00"; } extension module-version { argument "semver" { yin-element false; } description "The version number for the module. This is expressed as a semantic version number of the form: major.minor.patch(x) where: * major corresponds to the major version. * minor corresponds to a minor version. * patch corresponds to a patch version. It is updated only for 'editorial' changes that do not change the API semantics in any way. In addition to 'editorial' changes that do not change the YANG module semantics, the patch field can also be used in a limited way to indicate major and minor version changes as well. The patch version may be incremented for a major or minor change if that change is happening on a non-HEAD or non-latest branch. If the patch field is incremented for a minor version change then it is appended with the suffix '(m)', if the patch field is incremented for a major version change then it is appended with the suffix '(M)', replacing '(m)', if present. This version number should be specified as a child of revision statement to indicate that a specific revision had a specific semantic version number. Where several modules are used to build up a single block of functionality, the same module version is specified across each file that makes up the module. Following a release of major version 1, all modules will update 'major.minor.patch' version number as follows: 1. if one or more non-backwards-compatible change is made then either the major version number MUST be updated (resetting the minor and patch version numbers to 0) or only the patch version number MUST be updated and appended with '(M)', replacing '(m)' if present. 2. if one or more backwards-compatible change is made then either the minor version number MUST be updated (resetting the patch version numbers to 0) or only the patch version number MUST be updated and appended with '(m)' unless the previous patch version number already had '(M)' appended, in which case the '(M)' suffix is retained for the new patch version. 3. if one or more editorial change is made then the patch version number MUST be updated. If the previous patch version number already had either an '(m') or '(M)' suffix then it is retained for the new patch version regardless of whether the subsequent changes are backwards-compatible, non-backwards-compatible, or editorial changes. When a field in the version number is incremented, all following fields are reset back to 0. Major version number 0 indicates that the module is not yet stable and allows non-backwards-compatible changes without requiring the major version number to be incremented Where possible, the version number should be updated using the standard semantic versioning rules, relying on the '(m)' and '(M)' suffixes only used where strictly necessary."; } } // module cisco-semver
© 2023 YumaWorks, Inc. All rights reserved.