The second is the version skew problem. Once we have stable versions, we need a simple way of how downstream projects are updated. As it turns out, this is a *lot* easier from mechanical point (it typically changes just a single line), but explodes in validation complexity, as you need to play out a 'what-if' scenario across all projects and then either propose or directly apply the version bump to affected projects. Obviously we can have a guard in place, which will not perform this action if the downstream (consumer) project's committers have gone back in time to hotfix a regression coming from downstream. These should generally be exceptions and should be tracked automatically in some sort of dashboard, as the presence of version skew is a blocking problem for a simultaneous release.

I have started addressing this particular issue. As it turns out, reworking dependency management renders our current way of building karaf features utterly unusable, since the artifact versions disappear from maven properties.

Patch https://git.opendaylight.org/gerrit/#/c/11910/ introduces a new artifact which provides infrastructure for processing a features template, resolving versions from the artifacts dependency tree. I will propose migrating this piece into the odlparent project in a separate thread.

Patch https://git.opendaylight.org/gerrit/#/c/11911/ makes use of the above in the yangtools feature. It also changes the parent of features-builder, but that is only interim to get at the version declarations.

Finally https://git.opendaylight.org/gerrit/#/c/11845/ goes in and reworks the version tracking. It does so by introducing yangtools-artifacts, which does not have a parent and only has a dependencyManagement section. This is then imported into yangtools-parent, and thus reused everywhere. It can also be imported into downstream projects, without interfering with them at all. An example of this is commit https://git.opendaylight.org/gerrit/#/c/11942/, which does this for the controller project.

Bye,
Robert