| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| <html> |
| <head> |
| <title>Eclipse (Platform, JDT, PDE and Equinox) Release Engineering Build Schedule</title> |
| <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> |
| <link rel="stylesheet" href="https://www.eclipse.org/default_style.css" type="text/css"> |
| </head> |
| |
| <body bgcolor="#FFFFFF" text="#000000"> |
| |
| <h2 id="schedule">Eclipse Release Engineering build schedule</h2> |
| <h4>Platform, JDT, PDE: |
| <a href="http://download.eclipse.org/eclipse/downloads/">Downloads</a>, |
| <a href="https://www.eclipse.org/eclipse/development/">Plans</a>; |
| Equinox: |
| <a href="http://download.eclipse.org/equinox/">Downloads</a>, |
| <a href="https://projects.eclipse.org/projects/rt.equinox/next-release">Plans</a>. |
| See also the <a href="https://wiki.eclipse.org/Simultaneous_Release">Simultaneous Release</a> plans. |
| </h4> |
| |
| <font class="indexsub">Last change of static content: 2018-09-20.</font> |
| |
| <p> |
| I-builds use branches specified in <a href="https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/production/streams/repositories_master.txt">repositories.txt</a> 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. |
| <br> (daily 18:00 <a href="https://en.wikipedia.org/wiki/Eastern_Time_Zone">Eastern Time</a>, EST/EDT, -0400/-0500) |
| </p> |
| |
| <p> |
| <a href="https://calendar.google.com/calendar/ical/prfk26fdmpru1mptlb06p0jh4s%40group.calendar.google.com/public/basic.ics">ICAL Calendar URL</a> |
| </p> |
| |
| <iframe src="https://calendar.google.com/calendar/b/1/embed?mode=AGENDA&height=600&wkst=1&bgcolor=%23FFFFFF&src=prfk26fdmpru1mptlb06p0jh4s%40group.calendar.google.com&color=%23B1365F&ctz=America%2FNew_York" style="border-width:0" width="800" height="600" frameborder="0" scrolling="no"></iframe> |
| <h4 id="rebuilds">Rebuild Policy</h4> |
| <ul> |
| <li>Mondays' integration builds - rebuild if compile errors, missing plug-ins, the build is unusable, or if the drops do not get posted.</li> |
| <li>Other integration builds - rebuild on request for serious or urgent issues.</li> |
| </ul> |
| |
| <br> |
| |
| <h4 id="retention">Build Retention Policy</h4> |
| |
| <p>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.</p> |
| <ul> |
| <li>Release builds are kept indefinitely and moved to the archive.eclipse.org server as appropriate.</li> |
| <li>The last four integration builds are retained in the I-build repository.</li> |
| <li>Mondays' integration builds are retained until the release is available.</li> |
| <li>Stable builds are retained until a release is available.</li> |
| </ul> |
| |
| <br> |
| |
| <h4 id="notes">Build Notes</h4> |
| |
| <strong>For the 4.<i><n></i> Mondays' integration builds: </strong> |
| <ul> |
| <li>Build time is 18:00 (Eastern time).</li> |
| <li>In the event of an integration build failure due to compile errors, missing plug-ins, or if the drops are not posted,<br>there will be a same day rebuild upon |
| submission of a fix.</li> |
| <li> In the event of multiple integration build failures due to problems in the submission (i.e. not infrastructure problems), |
| <br>all other work will stop until guaranteed-to-be-successful build contributions are prepared for a rebuild.</li> |
| </ul> |
| |
| <br> |
| |
| |
| <p>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. </p> |
| |
| <p><strong>IMPORTANT</strong>: 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.<i><n></i> 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. </p> |
| |
| <h4 id="milestones">Milestone Weeks</h4> |
| Here's the usual schedule for milestone weeks: |
| <ul> |
| <li>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.</li> |
| <li>Tuesday: All-day test pass. Nobody should develop or fix anything. Literally spend the entire day testing.</li> |
| <li>Wednesday: Fix day with a focus on fixing regressions found during the test day (Tuesday). No unrelated fixes. Review and thoroughly test all commits. |
| <ul> |
| <li>The last Wednesday build is the release candidate every team signs off on Thursday.</li> |
| <li>The "New and Noteworthy" entries are due on Wednesday evening:<br> |
| Git repo: <code>ssh://git.eclipse.org/gitroot/www.eclipse.org/eclipse/news.git</code><br> |
| Gerrit: <code>ssh://git.eclipse.org:29418/www.eclipse.org/eclipse/news.git</code><br> |
| Live website: <a href="https://www.eclipse.org/eclipse/news/4.10/">https://www.eclipse.org/eclipse/news/4.10/</a></li> |
| </ul> |
| </li> |
| <li>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.</li> |
| <li>Friday: Build is officially declared and made available. |
| <ul> |
| <li>The master branch stays closed until the milestone is officially released. (That is, it is not enough that your component has signed off.)</li> |
| </ul> |
| </li> |
| </ul> |
| |
| </body> |
| </html> |