Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "SimRel/Overview"

m
(4 intermediate revisions by 2 users not shown)
Line 15: Line 15:
 
Projects are required to demonstrate conformance of a collection of "[http://eclipse.org/indigo/planning/EclipseSimultaneousRelease.php must dos]" (things that a project "must do" to participate).
 
Projects are required to demonstrate conformance of a collection of "[http://eclipse.org/indigo/planning/EclipseSimultaneousRelease.php must dos]" (things that a project "must do" to participate).
  
We have a [[Eclipse_b3/aggregator/manual|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. The Eclipse "Orbit" repository, which contains IP-cleared "bundlized" third-party libraries, is included in the aggregator to resolve bundle references to those libraries.
+
We have a [[Eclipse_b3/aggregator/manual|build aggregator]] that runs when changes to contributions are detected. 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. Occasionally, while building up to a milestone or release, the aggregated repository is moved to a [http://download.eclipse.org/releases/staging/ "staging" repository] for early testing by committers, and once final, the staging area is moved to a [http://download.eclipse.org/releases/indigo/ "releases" repository]. To know when things are "final", we do not have an "affirmation" check-off, but depend simply on the planned date, and then rely on the projects to notify us on cross-project list if they are late, need a little more time, or need a re-build for some serious problem after their agreed offset.  
  
On "+4" the build meister manually runs the the build and pushes the result to a public location for general consumption.
+
On "+4" the [http://www.eclipse.org/epp/ EPP] build meister runs the build for "all in one" distributions, and pushes the result to [http://www.eclipse.org/downloads/ a public location]. Typically, those files are allowed to mirror for approximately 24 hours before being made "visible" to the general public, so that once the general public start downloading them, not all downloads have to go through one single network.  
 
+
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 [[Helios/Final_Daze|Final Daze]] document.
 
The release train end-game is carefully coordinated as the final release date approaches. This end-game is outlined each year in the infamous [[Helios/Final_Daze|Final Daze]] document.
  
[[Category:Indigo| ]] [[Category:Coordinated]]
+
 
 +
[[Category:Kepler| ]] [[Category:Juno| ]] [[Category:Indigo| ]] [[Category:Coordinated]]

Revision as of 12:23, 1 July 2012

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 when changes to contributions are detected. 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. Occasionally, while building up to a milestone or release, the aggregated repository is moved to a "staging" repository for early testing by committers, and once final, the staging area is moved to a "releases" repository. To know when things are "final", we do not have an "affirmation" check-off, but depend simply on the planned date, and then rely on the projects to notify us on cross-project list if they are late, need a little more time, or need a re-build for some serious problem after their agreed offset.

On "+4" the EPP build meister runs the build for "all in one" distributions, and pushes the result to a public location. Typically, those files are allowed to mirror for approximately 24 hours before being made "visible" to the general public, so that once the general public start downloading them, not all downloads have to go through one single network.

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