On 03/30/2017 02:45 PM, Gunnar Wagenknecht wrote:
On 30. Mar 2017, at 19:10, Daniel Megert <daniel_meg...@ch.ibm.com> wrote:
I have never seen an announcement from Orbit that service release builds for
Orbit got dropped, but that seems to be the current reality, see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=509412#c19.
I'm not entirely sure we ever officially had a maintenance/service build story
in Orbit. Shouldn't the retention policy keep old bundles in place so that
projects referencing those would still consume them during the Neon series?
FWIW, I recall that David did create a "maintenance" branch for a Mars SR back in the
days but that was more of an "ad-hoc" thing. I never remember using a maintenance branch
in Orbit.
We always had a maintenance build in Orbit when it was required. And we
deliberately kept it to as few changes as possible (i.e. only those that
were required and requested by a participant in the Sim. Release
maintenance/update release.
I think there is also another thing to consider. IMHO projects should stop
hard-pinning specific 3rd party versions in the feature.xml -
This makes builds and installs non-deterministic. That seems like a lot
to give up. This isn't just a theoretical nicety. Especially with third
party jars (when we do not always know what versioning or API rules they
follow). It implies one set of tests on installs/updates using the
"project's repository" and another set of tests on installs/updates from
the "Sim. Release repository" (times the number of prereq repositories,
in theory). And THEN anyone doing long term maintenance addressing
(possibly paying customer's) issues has to wade through the possibly
numerous versions of a "release" that slightly differ based simply on
which repositories were used to not only create the products, but also
which ones their customers used to do updates (times the number of
derivative products which might use other sets of repositories).
And, don't forget, the looser you make the constraints the more you are
leaving it up to p2 to decide the "optimal solution" -- which is not
always what you would expect and not always the same, from one run to
the next.
Gee, wouldn't it be nice just to build one big application instead of
all these pesky components. :)
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
