I notice we use replaces-version leaf to resolve packages/modules conflict. But I think it's very difficult for authors to determine this field on design time, because yang package dependencies path will be very long.
for example:
a package a with version 1.0.0 may include package b with version 1.1.0 and package c with version 1.2.0, and package c with version 1.20 may also include package b with version 1.0.0, which version of package b should be implemented?
dependencies tree:
+--a:1.0.0
|--+--b:1.1.0
|--+--c:1.20
|------+--b:1.0.0
I think we should refer to maven's implementation, use a mechansim to resolve conflict other than do it manully. For example ,we can use nearest-win strategy, the the length of denpendencies path is the same, then latest version win.
I notice we use replaces-version leaf to resolve packages/modules conflict. But I think it's very difficult for authors to determine this field on design time, because yang package dependencies path will be very long. for example: a package a with version 1.0.0 may include package b with version 1.1.0 and package c with version 1.2.0, and package c with version 1.20 may also include package b with version 1.0.0, which version of package b should be implemented? dependencies tree: +--a:1.0.0 |--+--b:1.1.0 |--+--c:1.20 |------+--b:1.0.0
I think we should refer to maven's implementation, use a mechansim to resolve conflict other than do it manully. For example ,we can use nearest-win strategy, the the length of denpendencies path is the same, then latest version win.
reference: https://www.digitalocean.com/community/tutorials/maven-dependency-tree-resolving-conflicts