MoDisco/HeliosTrain

Important dates

Release Milestones

Release milestones will be occurring at roughly 6 week intervals, and will be aligned with the Helios Simultaneous Release train.

M1 08/07/2009 3.6M1
M2 09/18/2009 3.6M2
M3 10/30/2009 3.6M3
M4 12/11/2009 3.6M4
M5 01/29/2010 3.6M5
M6 03/12/2010 3.6M6 (API Freeze)
M7 04/30/2010 3.6M7 (Feature Freeze)

Individual, milestone level plans for the components that make up the Eclipse Project can be found on the Eclipse Project Helios Plan page on the Eclipse wiki.

Our target is to complete 3.6 in late June 2009, in alignment with Helios. All release deliverables will be available for download as soon as the release has been tested and validated in the target operating configurations listed below.

Dates for builds after M7 will be found in the Eclipse Helios end-game plan, available near 3.6 M7.

Pre-requesite (for MoDisco)

Eclipse Project Requirements, it links to requirements dedicated to website and project infos (metadata).

Left menu requirements, and a specific link for project in incubation phase: Incubation phase.

Project Meta-Data

Development resources, main entry point to development resources.

Requirements for Participation

(examples from Galileo simutaneous release train)

Projects must have stated and demonstrated their intent to join Galileo by the M4+0 date.
Projects must have an project plan in XML format.
At least one person from each project must subscribe to cross-project bug inbox, i.e. edit Bugzilla prefs to watch "cross-project.inbox@eclipse.org". Build team members (or their designated alternates) from each project will provide communication channels: phone, mail, IM, IRC and will be available during the milestone integration periods.
Project representatives must attend the planning meetings and conference calls - you have to be involved to be involved.
Projects must have a written ramp down policy by M6+0, linked in the table above pending inclusion of ramp down element in the XML project plan. (One of the issues identified with this guideline is that its not so much the ramp down policy of how many votes are needed for each bug fix that we need to be consistent on, but rather the meaning of each of the milestones and release candidates. See Platform 3.4 Endgame plan as a guideline. See also http://wiki.eclipse.org/Galileo/Final_Daze Galileo Final Daze].)
Projects must have their IP approved (a normal Eclipse requirement) and will follow the Eclipse Legal deadlines to do so.

Requirements for Releng

Projects must have build process maturity: scripted, repeatable, and executable by others.
Projects must optimize their own update site using pack200 to reduce bandwidth utilization and provide a better update experience for users. With the introduction of p2, project update sites must generate metadata (artifact and content repository info).

a guide to migrate update site to p2.

Must have New & Noteworthy for each milestone. Must be something readable and usable not just a static list of all the bugs, e.g. platform. Corollary: individual new & noteworthy should be linked in to the collective New & Noteworthy.

Requirements for Deployment

Each project will provide basic capability/activity definitions to allow for their UI contributions to be hidden. These must be provided in a separate plugin/feature to facilitate inclusion/exclusion by consumers in product development.
Each project will provide basic capability/activity definitions to allow for their UI contributions to be hidden. These must be provided in a separate plugin/feature to facilitate inclusion/exclusion by consumers in product development.
Must use ICU4J.