The first sentence of section 5.1.1 says “modules need to be imported using specific revisions”.
To me, this means that all imports should hardcode the imported module’s revision. This seems to be a lot of work in the long run, especially if you have 50+ YANG files (it is a large project). Once the revision is a date, this may get worse since it leads to individual file versioning and dependency mapping becomes nearly impossible.
I say impossible because its manual labor and when compared with modern database tools that provide data migrations. These tools do the heavy lifting of revision and dependency management, and there is no similar tool for the YANG environment.
Regarding Versioning Strategy for YANG files, my current take is:
- Imports don’t use revision. They will use latest;
- When releasing a new firmware version, run a script that updates all YANG file revisions to “code-freeze” date. If any YANG file changes after code-freeze, run the script again;
This eliminates the revision compatibility problem as long as you are in the same firmware version.
I wonder what you guys are doing, and what do you think about this strategy?
To set basic knowledge and assumptions on this topic, please read Lion Hack’s Versioning Strategy article.