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

[Roland Grunberg <rgrunber@xxxxxxxxxx>]

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

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.

Ideally, project contributing to Neon.3 should adopt the repository
that we would be releasing as our Neon.3 contribution. They could certainly
continue using our Oxygen milestone for Neon.3 but there are some downsides
to that :

- miletsone (S) builds only need to be retained until the Oxygen R build
is released so if projects / consumers ever needed to rebuild their Neon.3
branch after Oxygen was released it might fail to resolve the orbit S build
and they'd have to change to the Oxygen R-build on that branch

- The current Orbit Oxygen builds have removed some content (so far mainly
from the Docker Client / Jersey stack) and may continue to remove things
which wouldn't be nice for consumers. Of course they could simply list two
p2 Orbit repos (an Oxygen milestone, and the Neon R-build) but releasing
something specifically for Neon.3 seems nicer.


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

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 ?

Cheers,
-- 
Roland Grunberg