Orbit/Promotion, Release, and Retention Policies
Orbit itself does not have releases, per se, since the 3rd party jars that are bundled have already been released. But, we will still use the Eclipse Simultaneous Release rhythm to set deadlines for ourselves and promote and retain bundles.
An Orbit milestone date will be considered the same as the base Eclipse platform milestone date, since for anyone in a Simultaneous Release to use an Orbit Bundle, it would have to be ready (and final) at least a week or two before their milestone deadline.
Our continuous builds produce builds in the committers area. Their purpose is for the committers to have something to see or download and confirm all is as they expect it to be. These builds are often short lived and can be deleted without notice.
Weekly Declared Builds
Once per week, currently by Monday noon (Eastern time), the latest continuous build will be copied over to the downloads area. These are similar or analogous to weekly Integration Builds, and will be retained in place until the Milestone release.
Milestones and Recommended ("Final") Bundles Area
Once per milestone, (roughly simultaneous with the platform's milestone), the most recent Weekly Build will be declared the milestone build, and the earlier weekly builds deleted. The bundles from that milestone build, that committers judge as finished, will be copied to the downloads directory. This is to be considered the final home for the bundles added to Orbit. That is, these final bundles should not normally ever have to be re-built. In case they do, they will have different qualifiers in the fourth field. In this case, the older qualified versions will be kept for approximately 1 milestone period, to give consumers a chance to update any build scripts, without suddenly breaking their builds. We anticipate it being very rare to have to change a bundle after being moved to the final bundles area. Each Milestone Build will be retained until an Eclipse Simultaneous Release and then all deleted.
Issue: This permanent home for the bundles will not have "timestamp" directories, so it is easier to specify a permanent URL, write scripts, etc. The issue is that while these can currently be easily obtained one by one, but we have not yet decided what, if any, archive or update files to create for these final bundles.
It was decided in June 12, 2007 status meeting to (still) have dated directories for the "final" builds, and was decided to call them "R-builds", which may sound like "Released", but is "Recommended" for Orbit, since Orbit does not have Releases in the Eclipse sense of that word. The bundles in "Recommended" builds will only be changed (re-created) if there are serious bugs found with them. Even then, any "Recommended" builds will be retained long term, such as for 2 years or so, so build scripts will not break and be recreatable. It is expected that Recommended builds will be produced once or twice per year. Certainly for any yearly trains, but perhaps at other times, since not all projects always have to release only in June.
The Orbit milestones dates will be a -1 delivery in Simultaneous Releases, to allow all projects to pick up prereqs (even the Platform, the 0 delivery).
Milestone builds will be retained until the Recommend build is produced.
Recommended builds will be kept forever, the most recent one(s) on 'download.eclipse.org' but older ones will be moved to 'archive.eclipse.org' (which is not mirrored) The old, archived builds should rarely be needed, used only be used if someone needed to re-create some old build which was based upon it, such as for long term maintenance.
We will have a long term retention policy for multiple versions of bundles, to be sure it doesn't grow indefinitely over the years. By policy, we will retain up to 3 versions of a bundle and after that, the older versions will be removed from active builds and repositories. Those older versions will of course still be in any archived builds, if they were ever used in a Recommended build. These 3 versions do not mean qualified versions, but means, for example, minor and service versions, such as Xerces 2.8.0, 2.8.1, and 2.9.0. Once 2.9.1 was put in the repository, 2.8.0 would be removed from active builds and repositories. Eclipse Projects may request waivers to this policy if needed for some specific cases (just open a bugzilla with what you need, why, and for how long, if known).
Comments from Martin Oberhuber and Kim Moir:Moved to the "discussion" tab