Re: [orbit-dev] Final Stable build ... and next to Final build?

[DJ Houghton <DJ_Houghton@xxxxxxxxxx>]

orbit-dev-bounces@xxxxxxxxxxx wrote on 06/08/2007 12:29:44 PM:

>
> 1. I suggest that today we promote the latest 'committers' S build
> to 'downloads' for some folks to use for their final RC3 builds, and
> perhaps Platform could use that for final RC4 build? Or, is it too
> late for Platform's RC4?
>
Speaking for the Platform.... The bundles in Orbit which are consumed by
the Eclipse SDK have had their about files blessed by the powers that be
and good versions appear in the latest Orbit commiters stable build. There
are, however more bundles which need to be verified (those consumed by the
Equinox builds, for instance) and this will not be done until next week.
So rather than change the map files twice, the Platform will wait until
next week before we update our builds to contain the new Orbit stable
build.

> 2. I think we need to fix the "pre-built" processing,  bug 178723,
> before we are "final" (and, ironically, I think Platform is only one
> affected by this ... only one to use those pre-built jars).
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=178723
>
> 2b. I think I can fix that "bug" over weekend, so should be ready next
week.
>
> 3. Are we all set on the IP xml files? At some point something was
> going to be produced during builds? But, I've lost track.
>
My fault. I just realized like 5min ago that I have commit rights to the
Orbit Releng Tools project and can make code changes there. I will release
some code soon. There is a JAR in
org.eclipse.orbit.releng.builder/scripts/tools that needs to be updated. Is
that the only copy of the code? Do I need to do anything special with this
project or will the changes be picked up automatically?

The only thing left to decide is where the output html file should be
placed. Suggestions are welcome.


> 4. I do think we need a "final" area, Perhaps just called
> "released". BUT, I am not sure how we would then handle changes
> required to any bundles in that released area. I would not expect it
> to be frequent, but occasionally I'm sure there will be
> fixes/improvements needed -- and sometimes there _might_ be a "sev
> 1" sort of bug where some bundle is really broken. If we leave the
> "released" URL unchanged, then the .qualifier of a bundle could
> change for someone using that area.
> Normally, I suspect this is "good" (fixes bugs) but, some would
> consider "bad" (changes their repeatable build).
> So ... how to handle? Have "evolving" release areas? And clients
> could decide which they wanted to use? Or, should we really focus
onhaving a
> single URL repository ... and that repository URL would never
> change, though it's contents might.
>
> 4b. Oh, duh, how about both? A persistent, URL repository where the
> contents might change, if bad bugs found, but still "persist" the
> dated 'release' URLs?
>
Lets talk about this on the call next week. Pascal and I started talking
about it and things got complicated. :-)

> 5. My guess is end-of next week would be earliest we could have a
> final version (with any confidence). How "late" is this for Platform?
>
No official Platform builds are scheduled for next week but we anticipate
there will be a doc-only re-build at which point we will update the orbit
map. (as mentioned in #1 above) I think that a date like Wednesday might be
better than end of the week, though.