I have asked that several times already, but why do we allow individual projects to contribute Orbit bundles to simrel anyway? If the simrel aggregator would pull in the required Orbit bundles alone, it would have full control over which versions are bundled. Projects might yet bundle them in their own repositories (in dedicated features that are not promoted to the simrel aggregator), but IMHO even that could be avoided if the pointed to a respective simrel repository, from which to pull in third-party dependencies.
Cheers, Alexander > Am 31.03.2017 um 05:38 schrieb David Williams <david_willi...@acm.org>: > > 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 -- Dr. Alexander Nyßen Dipl.-Inform. Principal Engineer Telefon: +49 (0) 231 / 98 60-202 Telefax: +49 (0) 231 / 98 60-211 Mobil: +49 (0) 151 / 17396743 http://www.itemis.de alexander.nys...@itemis.de itemis AG Am Brambusch 15-24 44536 Lünen Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 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
