A problem reported as bug 174441 dealing with FormColours has been deemed major enough to warrant a 3.3M5a build in the near future. The problem can be traced down to:

FormColors.getColor(FormColors.TB_GBG) 

which returns null , whereas before in Eclipse 3.3M4 it returned a colour.

In actual fact, the Eclipse release/build train is pretty good at catching errors and integration points -- but 3.3M5 is the 'lockdown' of the API, after which changes to the API itself need to get sign-off from the appropriate leads. As a result, there's usually a larger number of changes that get integrated into the 3.3M5 builds and (over the last few years, at least) some of these changes have caused problems in dependent projects, with rebuilds being generated for 3.1M5a, 3.2M5a and now 3.3M5a. I observed before that the 3.xM5a came out a few days afterwards -- this time, the bug has resurfaced a good week later (and the decision to re-release 3.3M5a a few days after taht).

The fact is that given a project as large, distributed and as complex as Eclipse is an immense achievement by all the commiters, project leads and build team; and the agile nature of the builds means that everything has been kept in step for the last several releases. It's even more impressive when you consider that the core platform team usually make changes which then propagate down the line to other dependent teams, who then make changes and propagate down to their teams, and so on. The fact that it works as well as it does with only the occasional hiccough is testament to the good planning (and processes) put in place.

I suspect that the M5a is a rite of passage. Once you know that's out of the way, it's all downhill from there. And I'm sure that everyone at EclipseCon will have 3.3M5a installed by the time they get there

Alex.