Skip to main content
Jump to: navigation, search


< SimRel
Revision as of 13:56, 24 March 2011 by David (Talk | contribs) (removed inaccurate Orbit statement)

Here is a brief overview of how our Simultaneous Release works.

Individual projects opt to participate in our simultaneous release. i.e. a subset of Eclipse projects choose to participate. Non-participating projects just do their own thing.

Each participating project is responsible for doing their own local build. They are free to use whatever technology makes sense to them.

Each project is required to have at least one representative on our cross-project mailing list to monitor and participate in simultaneous-release-specific communication. Communication is pretty key early on to avoid things like dependency duplication (multiple versions of the same library) and such. We've had great success with reducing other redundancy with this simple step. The Web Tools project, for example, used to have its own database tools; communication lead to them scrapping that development in favour of adopting the work of the Data Tools project.

Each project is required to conform to the published release schedule. The schedule includes a total of seven (7) milestone, four (4) RCs, and one GA. Projects decide on an offset. The Eclipse project has, for example a "+0" offset: they provide their bits on the first day of any given milestone or RC date. A project like EMF is "+1" meaning that they provide their bits one day after the milestone or RC date. This basically indicates that EMF "depends on" Eclipse; they use the extra time to pull down the milestone/RC bits from their dependencies and run tests before they contribute their own bits to the milestone/RC. There are "+2" and "+3" projects as well. i.e. BIRT is "+2" because it depends on a number of "+1" projects.

Projects provide their bits as a p2 repository. They also provide some metadata that describes their contribution (e.g. location of said p2 repository, contact information of the provider, categorization information, etc.)

Projects are required to demonstrate conformance of a collection of "must dos" (things that a project "must do" to participate).

We have a build aggregator that runs continuously. It picks up all the bits and produces an über repository of everything that's currently available. So on offset "+2", the über repository should contain all the bits from all the projects that declared as "+1" (so the repository can be used by the "+2" projects to test). During aggregation, dependency problems may be discovered. If dependencies cannot be resolved, the offending project bits are excluded and an email is sent to the cross-project list for mitigation.

On "+4" the build meister manually runs the the build and pushes the result to a public location for general consumption.

As for individual project builds, there are a few technologies that are pretty well used. PDE Build is very common, but Hudson/Maven/Tycho are gaining a lot of momentum. A common use case is to define a version-specific build on Hudson. Hudson does the check out and invokes Maven on the project's top-level pom.xml. Tycho can be configured to build an update site which gets pushed out to our download server.

The release train end-game is carefully coordinated as the final release date approaches. This end-game is outlined each year in the infamous Final Daze document.

Back to the top