[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [orbit-dev] Build Links
- From: Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>
- Date: Mon, 22 Feb 2010 15:37:54 +0100
- Delivered-to: firstname.lastname@example.org
- Openpgp: id=0745A1E3
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:188.8.131.52) Gecko/20100216 Lightning/1.0b1 Thunderbird/3.0.2
Am 22.02.2010 15:15, schrieb DJ Houghton:
> I'm not sure I like the idea of a generic link. What would the
> repository look like? Would it be a composite repository pointing to X
> previous stable builds? What is the retention policy for this repository?
Just to be clear. I'm not proposing a composite repository. I just
thought of a small "ln -s ..." which would be part of the publish
script. It's similar to what Hudson offers. It's actually a *link* to
the last produced release.
> For me, the thing about including Orbit bundles in my build is that I
> want a specific version.
Right. That's why there is a "version=...." attribute in the p2 fetch
factory. This uniquely identifies the version.
> The problem with a generic URL for the repo
> location is that if it is rolling, composite, etc there is a chance that
> my bundle version has been removed without me knowing.
That's similar to the current situation. It can happen today that a
build gets removed. Thus, the bundle cannot be found anymore. Therefore,
we have to update our map files periodically to point to new builds even
thought the version of the dependency hasn't changed.
> With the current format I know exactly what version of my bundle I am
> getting and I am ensured that it exists in the repo I am pointing to.
I'm not proposing to change pointing to a specific version of a bundle.
My concern is that I have to update map files because repos get removed
although the bundle version didn't change.