Model Driven Approach: API Versioning

Tony Tkacik

Hi David,
That is good point and we as a community needs to figure it out - the API
version (YANG revision) was included into package name to signify
the change of the API contract - this versioning could be also achieved
with package versions in OSGI.

Without including revision in the package names the code could be easily
migrated to new version of YANG module if the changes we're backward
compatible (and should be if the author of module updates the module
with section 10 of RFC6020 in mind).

The inclusion of revision also allows for components, which could use
multiple revisions of API contracts simultaneosly, but I think
this will be very rare.

Also other is should we generate package names
from YANG module name (which is easily readable, but there will be chance
of conflicts) or from XML namespace which identifies module.

Tony Tkacik


I just finished watching the demo (had to leave the call early), this
may be a small point, but one thing I noticed was the API version was
being embedded in the package name, I am curious how this is intended to
work with non-generated code that depends on the package names remaining
the same?