Eclipse Release Engineering build schedule

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

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 18:00 Eastern Time, EST/EDT, -0400/-0500)

ICAL Calendar URL

Rebuild Policy

• Mondays' integration builds - rebuild if compile errors, missing plug-ins, the build is unusable, or if the drops do not get posted.
• Other integration builds - rebuild on request for serious or urgent issues.

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.

• Release builds are kept indefinitely and moved to the archive.eclipse.org server as appropriate.
• The last four integration builds are retained in the I-build repository.
• Mondays' integration builds are retained until the release is available.
• Stable builds are retained until a release is available.

Build Notes

• Build time is 18:00 (Eastern time).
• In the event of an integration build failure due to compile errors, missing plug-ins, or if the drops are not posted,
  there will be a same day rebuild upon submission of a fix.
• In the event of multiple integration build failures due to problems in the submission (i.e. not infrastructure problems),
  all other work will stop until guaranteed-to-be-successful build contributions are prepared for a rebuild.

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

• Monday: Last day of development (and even then, no "big changes"). After Monday 20:00 ET, no feature work or unrelated fixes are allowed -- only regression fixes.
• Tuesday: All-day test pass. Nobody should develop or fix anything. Literally spend the entire day testing.
• Wednesday: Fix day with a focus on fixing regressions found during the test day (Tuesday). No unrelated fixes. Review and thoroughly test all commits.
  • The last Wednesday build is the release candidate every team signs off on Thursday.
  • The "New and Noteworthy" entries are due on Wednesday evening:
    Git repo: ssh://git.eclipse.org/gitroot/www.eclipse.org/eclipse/news.git
    Gerrit: ssh://git.eclipse.org:29418/www.eclipse.org/eclipse/news.git
    Live website: https://www.eclipse.org/eclipse/news/4.10/
• Thursday: Sign-off after re-testing, or at least confirming no changes have been made to your component's code since the last time the component was tested well.
• Friday: Build is officially declared and made available.
  • The master branch stays closed until the milestone is officially released. (That is, it is not enough that your component has signed off.)