Re: [orbit-dev] Orbit release for Neon.3

[Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>]

> On 17 Feb 2017, at 08:07, Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx> wrote:

> There are, however, legitimate reasons to not use the latest and
> greatest. Code Recommenders, for example, sticks to Guava 15, as
> switching to the Guava version 21 now in the Oxygen Orbit repository
> would impose an unwanted Java 8 requirement on Recommenders' (pre-Neon)
> users.

Andreas, this is off-topic for the Orbit list but as a project your version range should be sane so that it works with latest Guava in Oxygen as well as older Guava in pre-Neon. 

You should not include a lower Guava version in your feature.xml but let p2 decide at installation time. This will avoid situations like the one below, which happen because project include different versions in their feature.xml when contributing to the common repository.

> What I really worry about is only marginally different versions of the
> same bundle being included in the simrel repository; at least for
> org.apache.httpcomponents we have seen wiring issues in the past
> (ClassCastExceptions, LinkageErrors). Of course, these are ultimately
> caused by bad metadata and should be fixed at the root, but a smaller
> number of nearly identical bundles means less risk.


>> Is the main worry that projects using something like "0.0.0" for versions
>> in their target platform might update to the latest Orbit repo and
>> unknowingly drag in a newer version of something they don't want ?
> 
> This problem hadn't even occurred to me and one would hope that the
> build fails if the newer version is incompatible in some way. But at
> least from a legal point of view, a 0.0.0 version may cause projects to
> distribute a bundle that they don't have a CQ for.

Projects using 0.0.0 as the version in their target platform and not a specific Orbit build URL but the Orbit composite should be well aware of these implications - legally as well as technically. AFAIK "0.0.0" has to be entered manually into the target file. By default PDE would pick a specific version.

In the case of distribution, the situation differs between an individual project download and a contribution to the common repository. If distributed via the common repository then a project may not (should not) contribute its specific version unless there is no one else contributing it already. If someone else is contributing it, then that project's CQ covers that properly.

-Gunnar