WIP: Extension validation for the YANG module versioning work

CMakeLists.txt

@@ -157,6 +157,8 @@ set(libsrc
     src/plugins_exts/yangdata.c
     src/plugins_exts/schema_mount.c
     src/plugins_exts/structure.c
+    src/plugins_exts/yang_semver.c
+    src/plugins_exts/yang_revisions.c
     src/xml.c
     src/xpath.c
     src/validation.c

models/ietf-yang-revisions@2025-01-28.yang

@@ -0,0 +1,146 @@
+module ietf-yang-revisions {
+  yang-version 1.1;
+  namespace "urn:ietf:params:xml:ns:yang:ietf-yang-revisions";
+  prefix rev;
+
+  import ietf-yang-types {
+    prefix yang;
+    reference
+      "RFC YYYY-draft-ietf-netmod-rfc6991-bis: Common YANG Data Types";
+  }
+
+  organization
+    "IETF NETMOD (Network Modeling) Working Group";
+  contact
+    "WG Web:   <https://datatracker.ietf.org/wg/netmod/>
+     WG List:  <mailto:[email protected]>
+
+     Author:   Joe Clarke
+              <mailto:[email protected]>
+
+     Author:   Reshad Rahman
+              <mailto:[email protected]>
+
+     Author:   Robert Wilton
+              <mailto:[email protected]>
+
+     Author:   Balazs Lengyel
+              <mailto:[email protected]>
+
+     Author:   Jason Sterne
+              <mailto:[email protected]>";
+  description
+    "This YANG 1.1 module contains definitions and extensions to
+     support updated YANG revision handling.
+
+     Copyright (c) 2024 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
+     Relating to IETF Documents
+     (https://trustee.ietf.org/license-info).
+
+     This version of this YANG module is part of RFC XXXX; see
+     the RFC itself for full legal notices.
+
+     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 (RFC 2119) (RFC 8174) when, and only when,
+     they appear in all capitals, as shown here.";
+  // RFC Ed.: update the date below with the date of RFC publication
+  // and remove this note.
+  // RFC Ed.: replace XXXX (inc above) with actual RFC number and
+  // remove this note.
+  // RFC Ed.: replace YYYY-draft-ietf-netmod-rfc6991-bis (inc above) with actual RFC number and
+  // remove this note.
+
+  revision 2025-01-28 {
+    description
+      "Initial version.";
+    reference
+      "RFC XXXX: Updated YANG Module Revision Handling";
+  }
+
+  typedef revision-date {
+    type yang:date-no-zone;
+    description
+      "A date associated with a YANG revision.
+
+       Matches dates formatted as YYYY-MM-DD.";
+    reference
+      "RFC 7950: The YANG 1.1 Data Modeling Language";
+  }
+
+  extension non-backwards-compatible {
+    description
+      "This statement is used to indicate YANG module revisions that
+       contain non-backwards-compatible changes.
+
+       The statement MUST only be a substatement of the 'revision'
+       statement.  Zero or one 'non-backwards-compatible' statements
+       per parent statement is allowed.  No substatements for this
+       extension have been standardized.
+
+       If a revision of a YANG module contains changes, relative to
+       the preceding revision in the revision history, that do not
+       conform to the backwards-compatible module update rules
+       defined in RFC-XXXX, then the 'non-backwards-compatible'
+       statement MUST be added as a substatement to the revision
+       statement.
+
+       Conversely, if a revision does not contain a
+       'non-backwards-compatible' statement then all changes,
+       relative to the preceding revision in the revision history,
+       MUST be backwards-compatible.
+
+       A new module revision that only contains changes that are
+       backwards-compatible SHOULD NOT include the
+       'non-backwards-compatible' statement.  An example of when an
+       author might add the 'non-backwards-compatible' statement is
+       if they believe a change could negatively impact clients even
+       though the backwards compatibility rules defined in RFC-XXXX
+       classify it as a backwards-compatible change.
+
+       Add, removing, or changing a 'non-backwards-compatible'
+       statement is a backwards-compatible version change.";
+    reference
+      "XXXX: Updated YANG Module Revision Handling;
+       Section 3.2,
+       non-backwards-compatible extension statement";
+  }
+
+  extension recommended-min-date {
+    argument revision-date;
+    description
+      "Recommends the revision of the module that may be imported to
+       one whose revision date matches or is after the specified
+       revision-date.
+
+       The argument value MUST conform to the 'revision-date' defined
+       type.
+
+       The statement MUST only be a substatement of the import
+       statement.  Zero, one or more 'recommended-min-date'
+       statements per parent statement are allowed.  No substatements
+       for this extension have been standardized.
+
+       Zero or one 'recommended-min-date' extension statement is
+       allowed for each parent 'import' statement.
+
+       A particular revision of an imported module adheres to an
+       import's 'recommended-min-date' extension statement if the
+       imported module's revision date is equal to or later than
+       the revision date argument of the 'recommended-min-date'
+       extension statement in the importing module.
+
+       Adding, removing or updating a 'recommended-min-date'
+       statement to an import is a backwards-compatible change.";
+    reference
+      "XXXX: Updated YANG Module Revision Handling; Section 4,
+       Guidance for revision selection on imports";
+  }
+}