Eclipse is held in high regard for a number of reasons. One of the most unsung is the consistent build schedule that keeps rolling out new versions of the software. If there were any advert needed on the benefits of agile software development, Eclipse would be at the top.

I've noted this before , but the relentless yearly schedule of milestone releases as well as the released versions can be charted on a calendar. Looking back:

Milestone	Eclipse 3.1			Eclipse 3.2			Eclipse 3.3			Eclipse 3.4
M1	12th	August	2004	11th	August	2005	10th	August	2006	10th	August	2007
M2	24th	September	2004	23rd	September	2005	22nd	September	2006	21st	September	2007
M3	5th	November	2004	2nd	November	2005	3rd	November	2006
M4	17th	December	2004	15th	December	2005	15th	December	2006
M5	21st	February	2004	20th	February	2005	9th	February	2006

That's some consistent release schedules. As other agile projects, the consistent schedule is managed by controlling the content of the project rather than the timeline; large stories are addressed over the entire lifecycle, and there the contents of the final release are based on what is tested and suitable for the release rather than letting dates slip and not making a final build.

The point releases are a good way of delivering bug fixes (but not new functionality) to ensure that any major issues or unresolved problems with the release are dealt with. This means that if new functionality doesn't get in place by the time that M5 (or M5a/ eh ) gets left out until the next release. This is sensible project management strategy to minimise the risk of problems, though since M5 is the last 'major' point of new functionality, it's been hit by the occasional issues in the past ( 3.1m5a , 3.2m5a , 3.3m5a ). Stay tuned for 3.4M5 ...

For those wanting to track, the platform release schedule is available with the plans for 3.3.1 in the near future as well.