Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] Predictable Simrel Updatesite
For WTP we create composite sites to point at the latest release. I have it nearly automated such that when we do a GA release it's a few clicks to run a job to regen the composite*.xml files. We used to do one per stream so we could update quarterly with .z releases, but now that we're doing a .y every quarter, these latest URLs are just ease-of-use pointers, eg., https://download.eclipse.org/webtools/repository/2018-12/?d -> https://download.eclipse.org/webtools/downloads/drops/R3.12.0/R-3.12.0-20181130055351/repository/

The job [2] takes two params: URL to update, and list of child sites in the composite. 

It's dead easy, and requires minimal effort to set up and use.


So, if you decide you want to publish a /latest/ site for your R builds in addition to your latest-I, there's one implementation you could use.


On Mon, Feb 4, 2019 at 10:31 AM Roland Grunberg <rgrunber@xxxxxxxxxx> wrote:
On Mon, 2019-02-04 at 12:22 +0100, Dietrich, Christian wrote:
> Hello Orbit Devs,
>
> For Eclipse Itself there is http://download.eclipse.org/releases/2019-03
> it is populated with the Milestones and later with the release.
> Is there any reason something like this does not exist for orbit.
> this would prevent clients from having to update to S and R releases
> that are declared to be used for milestones and releases.

We currently have something similar with latest-I [1] (also for S, and
R). However, I'm guessing you want something to set once in the target
platform, and leave there right through to the final release.

In the past, the argument against this was that the underlying content
of such repositories can change and sometimes this might cause issues.
If maintainers aren't explicit in which dependencies they need (eg.
0.0.0) they can end up silently using a 3rd party library they didn't
want, with no uses-CQ having been filed. At the end of the day, people
can always choose which approach suits them best.

What are people's thoughts on this ? I could certainly see it making
life easier for all projects to synchronize on the Orbit release,
especially in cases when we come in late (eg. needing an RC2) so I'd be
inclined to create such stable URLs.

Cheers,
--
Roland Grunberg

https://download.eclipse.org/tools/orbit/downloads/latest-I/

_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/orbit-dev


--

Nick Boldt

Principal Software Engineer, RHCSA

Productization Lead :: JBoss Tools & Dev Studio

IM: @nickboldt / @nboldt / http://nick.divbyzero.com



“The Only Thing That Is Constant Is Change” - Heraclitus

Back to the top