Eclipse, OSGi, Galileo and Release Trains

Ah, Eclipse Galileo is finally out for Friends of Eclipse, I just got the glorious email:

If we look at the annual releases of Eclipse, we have some nice consistency:

2004 - June 28th (Eclipse 3.0) 2005 - June 28th (Eclipse 3.1) 2006 - June 30th (Callisto) 2007 - June 29th (Europa) 2008 - June 25th (Ganymede) 2009 - June 24th (Galileo)

Can’t say that about many software projects as large as Eclipse!

With Eclipse releasing at the same time every year, I can say with confidence that we’ll see the next annual release of Eclipse (Helios) on June 24th, 2010. But why do this every year? Why get a bunch of independently run projects to release together?

Well, I think it’s simple… it helps spur the adoption of Eclipse technology. The consumers of Eclipse technology use many projects, not just the “Platform” projects so having the ability to get them at once is a good thing. Essentially, the latency between independently run projects is removed by having an annual release train. Another interesting benefit of having an annual release is that it allows for alignment of version compatibility which is hard to get right. There are many other reasons, but the important thing in my opinion is seeing many developers united around platform and building cool technology with it.

In the end, I’ve convinced myself that having these large annual releases of inter-dependent but independently run projects is only possible because of OSGi and modularity. OSGi allows for fences (API contracts) to be built around useful bits of functionality. As the saying goes, good fences make for good neighbors… and for good release trains.

Enjoy Galileo and see you next year for the Eclipse Helios release :)!