Build submissions are done before every integration build and milestone build. Integration builds typically occur on Tuesday. Please see the Platform Release Engineering page for more information. We do our build submission for an 8 a.m. build, at 4 p.m. the previous day.

If you miss the cut-off for the official build submission, but it is still before the build has started, then you can do your own build submission to make sure your fix gets into the build.

A warning email should be sent to "platform-ui-dev@eclipse.org" (or all committers) at the beginning of the days on which an official build submission is to occur, or if you do your own build submission.

The Platform-UI team suggests that the Release Engineering (releng) tool be installed before doing a build submission. It reduces the chance of error.

1. Exit Eclipse (if running)
2. Download the releng tool.
3. Unzip the tool into your plugins directory.
4. Start Eclipse

Before performing an build submission, it is the responsibility of the submitter to verify that the UI tests all pass. To perform a submission using the releng tool, please do as follows:

1. Select the project you need to version, and select "Team > Release".
2. Supply the name of the release. Our convention is to use vYYYYMMDD, where the date is the day of the build. If the name is already in use, then use a letter suffix (i.e., a, b, c, etc.).
3. The synchronize view will open showing the changes in the file "ui.map".
4. Continue to version all of the packages that you need.
5. When you are done, commit the changes to "ui.map".

To do a build submission using CVS, please do as follows:

1. Tag all projects you have changed with the name of the release. Our convention is to use vYYYYMMDD, where the date is the day of the build. If the name is already in use, then use a letter suffix (i.e., a, b, c, etc.).
2. Checkout "org.eclipse.releng".
3. Open "maps/ui.map".
4. Change the version(s) of the project(s) you have tagged.
5. Save the map.
6. Commit your changes to the map to CVS.

In the event of a test failure, our team must respond to eclipse-dev with one of two responses. We can say that we want a recovery build the following day. Alternatively, we can say that the test failure is not significant, and that the quality of the build should not be affected. (In either case, a bug should likely be entered into the bug database.)

A recovery build can also be requested if there is a problem affecting the usability of the build. This problem should make the build unusable for testing and development use.

For a recovery build, the map will need to be updated to include our fixes. This can either be everything on the head in CVS, or just the particular fixes we need. The former should only be done if no risky changes have gone onto the head since the last (i.e., the failed) build submission.