blob: c53bbd142af2c7a7ca586dbfd6304d59e46ebf22 [file] [log] [blame]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<title>Eclipse (Platform, JDT, PDE and Equinox) Release Engineering Build Schedule</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link rel="stylesheet" href="" type="text/css">
<body bgcolor="#FFFFFF" text="#000000">
<h2>Eclipse Release Engineering build schedule</h2>
<h4>(Platform, JDT, PDE and Equinox)</h4>
<font class=indexsub>static content last updated 2013-05-17</font>
I-builds use branches specified in <a href="">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.
N-builds always use 'master' branch of the repositories built.
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.
<li><a href="">XML</a></li>
<li><a href="">ICAL</a></li>
<iframe src="" style="border-width:0" scrolling="auto" width="800" height="600" frameborder="0"></iframe>
<h4>Rebuild Policy</h4>
<li>Nightly builds - No rebuilds</li>
<li>Integration builds - Same day rebuild if compile errors, missing plugins, the build is unusable or if the drops do not get posted.Otherwise, a rebuild the next day at 8:00am.</li>
<li>Maintenance builds - Rebuild until success</li>
<h4>Build Retention Policy</h4>
<p>In an effort to reduce our disk utilization on the infrastructure and reduce the amount of data sent to the mirrors, we have adopted the following build retention policy.</p>
<li>Release builds are kept indefinitely and moved to the server as appropriate</li>
<li>Four integration and nightly builds are retained</li>
<li>Maintenance builds are kept until a release of the maintenance stream is available.</li>
<li>Stable builds are retained until a release is available.</li>
<h4>Build Notes</h4>
<strong>For the 4.<i>&lt;n&gt;</i> Integration builds: </strong>
<li>build time is 8:00 am (Eastern time) on Tuesday mornings.</li>
<li>In the event of an integration build failure due to compile errors, missing plugins or if the drops are not posted,<br>there will be a same day rebuild upon
submission of a fix.</li>
<li>Otherwise, there will be a rebuild at noon Wednesday morning to accommodate fixes that have a workaround or do not impact the general usability of the build.
<li>Teams are expected to indicate on the platform-releng-dev mailing list if they intend to contribute to a rebuild.</li>
<li> In the event of a double integration build failure, all other work will stop until guaranteed-to-be-successful build contributions are prepared for a rebuild at 8:00 am Thursday morning.</li>
<li> if the Thursday 8:00 am (Eastern time) integration build fails we will rebuild until success </li>
<li> once a good integration build is achieved, it will be marked as such on the website.</li>
<li> the Releng team will often request a go/no go status from all teams to determine if the build is suitable for the week's testing. If you provide status and then
recontribute to a subsequent build, you are required to revalidate the build and provide an updated status.</li>
<strong>For the 4.<i>&lt;n-1&gt;</i>.x maintenance builds: </strong>
<li>Build time is 8am Wednesday (Eastern time)</li>
<li>Due to the nature of the fixes in this stream, these builds should not fail. However, if a
rebuild is requested by one of the teams, it will take place as soon as the build contribution is available.</li>
<p>In the above descriptions, a build is considered to be a failure if there are &quot;Red X&quot;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>: This strategy <strong>requires</strong>
us to have good build inputs. All teams must use the tools to pre-build and test
their submissions. In addition, teams should track the nightly builds to detect
integration problems early on. What we want to achieve is for the Tuesday morning
4.<i>&lt;n&gt;</i> build to typically be successful, with an infrequent requirement for a
noon build. Failing the Wednesday noon rebuild 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>