Eclipse Release Engineering build schedule

Platform, JDT, PDE: Downloads, Plans; Equinox: Downloads, Plans. See also the Simultaneous Release plans.

Last change of static content: 2016-12-05.

I-builds use branches specified in repositories.txt file, from master branch of aggregator (eclipse.platform.releng.aggregator). The projects built are submodules of aggregator so normally there is one line in repositories.txt file for each submodule of the aggregator.
   (daily 20:00 Eastern Time, EST/EDT, -0400/-0500)

M-builds use a branch of the aggregator (and therefore a branch of the repositories.txt file) and, like I-builds, pull whatever branch is specified in the repositories.txt file.
   (usually Wednesdays, 04:00 a.m., Eastern Time)

ICAL Calendar URL

Rebuild Policy


Build Retention Policy

In an effort to reduce our disk utilization on the eclipse.org infrastructure and reduce the amount of data sent to the mirrors, we have adopted the following build retention policy.


Build Notes

For the 4.<n> Mondays' integration builds:
For the 4.<n-1>.x maintenance builds:

In the above descriptions, a build is considered to be a failure if there are "Red X"s that the developers agree represent valid reasons for them to not begin using the integration build. An example of a Red X which would *not* require a re-build would be a test which failed because the test was bogus.

IMPORTANT: Committers are expected to run tests before pushing changes to master or a maintenance branch. In addition, teams should track test failures to detect integration problems early on. What we want to achieve is for the Monday 4.<n> I-build to typically be successful, with an infrequent requirement for a rebuild. Failing builds until Wednesday should be treated as a catastrophic failure. In other words, more than two or three of these per year is an unacceptable failure rate.

Milestone Weeks

Here's the usual schedule for milestone weeks: