Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] Orbit release for Neon.3

Roland Grunberg wrote:
>>> This has been requested in the past and although I'm sure people might be
>>> using Oxygen S-builds for content they intend to consume in Neon service
>>> releases, these builds are only guaranteed to be retained up until the
>>> release of the Oxygen R-build. As a result, I wanted to give a heads up
>>> that I intend to create a Neon.3 R-build that will likely be based on the
>>> orbit-recipes bundles found in the Oxygen M5 build [1] and the old ones
>>> from the Neon R-build [2].
>>>
>>> If there are any concerns or objections to us providing such a build,
>>> feel free to post as part of this thread.
>>
>> A question: What's the recommendation for the versions to pick for Neon.3?
>>
>> Some common plug-ins (like com.google.gson) have been updated in the
>> meantime. Should projects contributing to Neon.3 switch to the Oxygen
>> version or stay at the version that was already in Neon? Either way,
>> this needs to be coordinated among projects if we want to avoid
>> "duplicate" bundles in the simrel repositories. And at least some
>> projects (I know of Mylyn at least) don't plan a dedicated Neon.3
>> contribution; for them Neon.2 == Neon.3, meaning that they will
>> contribute the older version of com.google.gson to Neon.3.
> 
> Whether projects choose to go with google-gson 2.2.4 (Neon R-build) or
> update to google-gson 2.7.0 (Oxygen M-build) should be up to them.
> Ideally we should always try to standardize on the latest but different
> versions of dependencies should be able to coexist as long as plugins
> have sane version ranges.

Agreed. If a project wants new functionality from a dependency and that
functionality is already provided by a newer version in the (Oxygen)
Orbit, then by all means it should be able to use and not wait for Oxygen.

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.

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.

> For a second I was thinking about the case where com.google.gson 2.7.0
> would have 2 different timestamps in the simrel if projects used both
> the Orbit M5, and Neon.3 builds. However, jgit-timestamp provider should
> guarantee they're the same because I'll be rebuilding off the exact commit
> used for Orbit's M5 contribution.

Great.

>> Based on the above, I would issue the following recommendation:
>>
>> - Use the bundle from the Oxygen M5 build only if the BSN is not in the
>> Neon.0 R-build or if the version in the Neon.0 R-build doesn't yet
>> contain all features you require.
>>
>> - Otherwise, stick to the version from the Neon.0 R-build.
> 
> So is this suggestion to simply not have a Neon.3 build that contains
> both Oxygen M5 (S-build) + Neon.0 R-build bundles and have consumers
> specify 1 or 2 p2 repositories depending on their need ?

My main worry is nearly identical bundles if some projects pick their
version from the Neon.0 R-build and others from the Oxygen M5 S-build.
Specifically, I wonder if there is a bundle in the two repositories that
differs by qualifier only, because it has been rebuild since June 2016.

A clear recommendation would solve this issue.

> 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.

That being said, all this issues can be overcome with communication and
coordination. :-)

Best wishes,

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

Attachment: signature.asc
Description: OpenPGP digital signature


Back to the top