[Netmod-ver-dt] Meeting today and next steps

["Rob Wilton (rwilton)" <[e-mail]>]

Hi,



I had a few discussions with various folks after the Open YANG Versioning DT meeting, in particular with Martin, but also with others later in the week.



The outcome of those some of those discussions is for a proposal to split the module level versioning into two parts, i.e. two separate drafts:



(1) YANG Language level revision management.

(2) Overlaid versioning schemes (such as semver) using a revision-date alias.



Now, I also know that not everyone on the DT has yet bought into this plan, and nor have I been able to discuss it with everyone yet.  But I think that it would be useful to discuss this in today's meeting, and on email (not everyone is able to attend today's meeting).



The key question is discuss is really: Do we try and decouple the basic rules for managing YANG revision history and branching from any associated versioning scheme?





For draft (1):

- This draft would incorporate quite a lot of what we have in the current draft, but without the definition of YANG semver.

- YANG revisions would be allowed to be arbitrarily branched.  I.e. the revision history in the module would indicate that path from leaf revision back to root revision.  Older revisions could probably also be pruned (can look at an old revision of the module to construct the full history).  Martin pointed out that technically RFC 7950 already allows arbitrary branching of revisions, i.e. it never actually states that the revision history has to be linear, even though that was the intention.

- There would be a new statement to indicate whether a revision included changes that are "nbc" (or perhaps split between "nbc", "bc" and "editorial"), which could also support a description substatement.

- They would be a new "alias" (or perhaps "version") statement that would allow a human interpretable name to be assigned to a revision.  This revision alias/version could also be used in the filename, and in import statements.

- There would be an import for "revision x or derived", where "derived" means chronologically later within one of the branched histories.  I.e. it is somewhat equivalent to the "1.1.0+" that we currently define in our current draft, but it is not quite the same.  There could also be a version of import that can use the revision alias/version instead.

- It was also proposed that we deprecate "import exact revision" and don't implement a range import at this time.  A ranged import could be added future if required, but it might be better to start simple and extend if needed in future.

- Most of this draft would eventually fold into RFC 7950bis.



So, this first draft would define:

1) a new extension statement to mark a revision as "nbc" (or perhaps "bc, nbc, editorial"), and perhaps also allow a description as a child statement.

2) a new extension statement to add an "alias" or "version" label to a revision.

3) Possibly updates to RFC 7950 chap 11 to define what "bc, nbc, editorial" changes are defined as (also fixing deprecated/obsolete)

4) filename conventions for using the alias/version.

5) "import by revision x or derived" and "import by alias x or derived".

6) Updated guidelines

7) How instance data is handled

8) YANG library additions to report "deprecated/obsolete".





For draft (2):

- This would describe various versioning schemes that could be overlaid on the basic version management.

- Owners of the module ecosystem can choose an appropriate scheme that matches their specific requirements.

- Versioning schemes described could include:

    - A strict backwards compatible linear version scheme.

    - The existing RFC 7950 versioning scheme (but allowing nbc changes to address bugfixes)

    - Strict Semver 2.0.0

    - YANG Semver (perhaps as described in the current draft)

    - Release based versioning.

- One open question is, how do we identify which versioning scheme is being used for a module?

- This draft would probably always exist separately from RFC7950bis.





Further stuff TBD:

  - Do we add extensions for the additional annotations to describe specific bc, nbc, editorial changes?  If so, which doc should these go in?



I would like the DT to consider whether this is a direction that we think that we should head in.  We can discuss over email, and in the DT meeting on Thursday.  I can certainly see some benefits in this approach because I think that it may be easier to get WG consensus, particularly because everyone isn't being forced to use exactly the same versioning naming convention.



I also believe that all of the other related work (packages, version selection, scheme comparison) continues to be important.



Thanks,

Rob