On 01/12/2017 05:38 PM, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) wrote: >> That work starts at leaf projects, which have to be able to cope >> with version bumps and version skew -- the first one being >> integration/distribution, >> which must not ensure it is pulling in exactly one version of each ODL >> artifact. > Can you elaborate? > > I imagine by the time Carbon is released, > features-index will be built using feature-repo-parent, > and its pom file will specify version ranges. > > I am not sure whether the generated repo would > refer to the same version ranges, or whether > it would pick the most recent versions available during the build. > > Then we can create a test which would verify > "exactly one version of each ODL artifact" is true, > but I am not sure what to do if that test fails.
Assuming we are *not* integrating on snapshots, that means that released versions of (say, yangtools) need to propagate down the project dependency chain, which means that at any given time unrelated projects, like bgpcep and netvirt, can be pulling in different releases of yangtools -- which means distribution will be pulling them in transitively via features. That obviously has to converge by SR RC0, such that the SR contains precisely one version of yangtools. Bye, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
