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 "Europa Simultaneous Release"

(Projects)
(Projects)
Line 2: Line 2:
  
 
===Projects===
 
===Projects===
The projects that plan to participate in the Europa Simultaneous Release are:
+
The projects that plan to participate in the Europa Simultaneous Release are: (and their milestone offsets are)
 
* [http://www.eclipse.org/eclipse/ Platform] +0
 
* [http://www.eclipse.org/eclipse/ Platform] +0
 
* [http://www.eclipse.org/webtools/ Web Tools] +1
 
* [http://www.eclipse.org/webtools/ Web Tools] +1

Revision as of 04:27, 15 October 2006

(This is the easily-community modifiable wiki page about the Europa Simultaneous Release. This page (and its siblings) should be the main developer information pages. The master page on the eclipse.org site mostly points here.)

Projects

The projects that plan to participate in the Europa Simultaneous Release are: (and their milestone offsets are)

Europa CVS Projects

A number of utilities have been written to automate the assembly of Callisto (and now Europa) builds. These are available in their own CVS respository. You can find more information about how this is organized and individual project responsibilities for the build on this Callisto build page.

Requirements For Participation

Projects that are part of Callisto agree to abide by the following requirements.

Must Do

These are required for participation:

  1. The projects must work together.
  2. Projects must have build process maturity and their own functional project update site - the Europa site will reference these sites, not replace them.
  3. Projects must use 4-part version numbers. However we also need to define what the semantics of the 4-parts are: when do the parts get updated.
  4. Project representatives must attend the planning meetings and conference calls - you have to be involved to be involved.

Should Do

These are strongly recommended for participating projects:

  1. Projects should have jar'ed plug-ins because this is good Eclipse citizenship.
  2. Projects should use Eclipse message bundles, not Java bundles because this is a good Eclipse citizenship.
  3. Non-project-team-members should be able to build each project.
  4. Non-project-team-members should be able to run unit tests on each project.

Recommended

These are suggested to the participating projects:

  1. (none yet)

Not Sure Yet

These are ideas that we (individually or collectively) have had and we (collectively) have not yet decided whether to incorporate them.

  1. (From Callisto) Projects must use ICU4J.
  2. (From Callisto) Projects must use capabilities. The problem with this requirement was the vagueness of what it meant to "use capabilities".
  3. (From Callisto) Projects should have a written ramp down policy.
  4. Projects should provide both run-times and SDKs through their update sites and thence through the Europa update site.
  5. Something about consistency around product/primary feature plug-ins.
  6. Something about distinguishing the maturity levels of the different projects.
  7. Projects must use signed plugins using the Eclipse certificate.
  8. At least one person from each project must subscribe to cross-project bug inbox
  9. Build team members from each project will provide communication channels: phone, mail, IM, IRC and will be available during to-be-specified crucial integration times
  10. Common plug-ins must be used via Orbit; no duplication allowed
  11. Source tarballs will be created for Linux with build scripts
  12. Projects will volunteer to help with staffing multiple central buildmeisters
  13. Process/procedure/mechanism for the releasing end-game will be documented on the wiki
  14. Written process for withdrawing a project that cannot/does not meet the requirements
  15. Choose dates so that it is all done in advance - not at the last minute.
  16. Participate in a collective New & Noteworthy
  17. Projects should follow the Version Numbering policy.
  18. Optimize your update site using pack200 to reduce bandwidth utilization and provide a better update experience for users.

Milestones and Release Candidates

These milestone and release candidate dates are based on the dependencies of the projects (we call these the +0, +1, and +2 dependencies). Obviously, if a +0 date slips, then it will cause the +1 and +2 dates to slip; similarly for a +1 slip causing +2 slips.

Candidate milestone dates:

+0 +1 +2
M4 Dec 15 Dec 21 Dec 28
M5 Feb 9 Feb 16 Feb 23
M6 - API Freeze Mar 23 Mar 30 Apr 6
M7 - RC0 May 4 May 11 May 18
RCn...
RCX Jun 15  ?  ?
Europa June 29

Conference Calls

Back to the top