| [cross-project-issues-dev] Declaring Orbit Juno Build and repository: R20120526062928 |
This will be the build and repository that Orbit offers to those contributing to Juno. Please move your build scripts (or those newfangled "POMs"? :) to use this new build/drop/repository.
http://download.eclipse.org/tools/orbit/downloads/drops/R20120526062928/repository/
The I and S builds produced during the year will be progressively removed over the next week and by 5/31 I plan to have them all removed. If this exact date is a problem for anyone, and you need a few extra days to make the changes required, just say the word, and what you need. Ideally everyone would move in time for next RC, so in some of the common repository reports, we can get a better idea if anyone is using incorrect bundles.
Such as, the non-unique-versions report looks pretty good (for Orbit bundle reuse)
http://build.eclipse.org/juno/simrel/reporeports/reports/nonUniqueVersions.txt
Remember, and this is always true, there is always a small chance someone might find a blocking problem in the next RC (or two) that might require a change in an Orbit bundle. But that would be extremely rare (and would really need to be a show-stopper, no mere bad bug will do). This is always the case, just wanted to remind everyone, especially new comers.
Good opportunity to give another important reminder, especially for new comers that applies for the rest of the year (dev cycle): Use only Orbit R-builds for your releases (even if off-cycle).
Wordy version: For Orbit bundles, you (your Eclipse Foundation projects) should only ever use "R-builds" in your own projects' releases, even if they are off-cycle. For example, if you release in April, May, or December, and use some I or S build, there is a great chance that bundle (not merely the URL) will disappear, since it may require changes by the time the R-build comes around, and the R-build bundles are the only ones we retain indefinitely. If you do have an off-cycle release, and you need something "new" in Orbit, that is not in an existing R-build, then you should ask, on orbit-dev list or in orbit bugzilla releng component (preferably through an Orbit committer) that there be another, off-cycle R-build of Orbit. This is actually true of any pre-reqs you might have on any other Eclipse Foundation Project, but Orbit causes the most confusion in this area (for understandable reasons) so thought I'd remind everyone now that we are quite happy to work with projects that need SR1, SR2, or even off-cycle, R-builds. We'll work out the details as the need arises, but you need to let us know of the need.
Thanks,
David M Williams---05/26/2012 02:25:30 PM--- Download Page:
From: David M Williams/Raleigh/IBM@IBMUS
To: orbit-dev@xxxxxxxxxxx, orbit-dev@xxxxxxxxxxx,
Date: 05/26/2012 02:25 PM
Subject: [orbit-dev] Declaring Build: R20120526062928
Sent by: orbit-dev-bounces@xxxxxxxxxxx
