Orbit Rampdown Policy

Note: The contents of this page are retained for historical significance. Please see https://github.com/eclipse/orbit#readme for current information.

Orbit itself does not have releases, per se, since the 3rd party jars that are bundled have already been released, and they are used by other Eclipse projects which have their own release cycles. But, we will still use the Eclipse Simultaneous Release rhythm to set deadlines for ourselves and promote and retain bundles.

There are a few implications for the rampdown phase of the yearly Simultaneous Release (and its associated maintenance).

First, we will produce our "Orbit build" at the -1 time frame ... one week before the Platform's +0 deadline. So, for example, for Helios Release, our rampdown deadlines are as follows, producing weekly builds if (and only if) required:

 05/07 (one week before RC1 +0)
 05/14 (one week before RC2 +0) 
 05/21 (one week before RC3 +0) 
 05/28 (one week before RC4 +0) 
 06/04 (one week before Final +0) 

Second, once we enter the 'release candidate' phase, we will only make changes required to fix bad bugs, as required by Eclipse projects for the Simultaneous Release. We would not, for example, change wording or add a new bundle unless it was required by the Simultaneous Release. While it could be argued, "no one else uses it, what harm could it cause", the counter argument is "why take a chance, even if small". There is always a chance something could go wrong with infrastructure, signing or similar things that could cause issues "at the last minute" and that's what we want to avoid. Even when we make other projects use a new URL, we are taking some chance they will make a typo and while not our "fault", we want to minimize all sources of potential problems.

On the other of stability, if there is a bug required for Simultaneous Release, we should fix it as soon as possible.

During the release candidate phase, in most cases, and certainly if a committer has any doubt, a note to orbit-dev list is appropriate so other Orbit committers can have a chance to review and advise if any fix or change is appropriate, or not.