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.
Difference between revisions of "STP/Ganymede Release"
< STP
(New page: ====Must Do==== These are ''required'' for participation: # The projects must work together. This means that one should be able to load any subset of the Ganymede projects into Eclipse and...) |
(→Must Do) |
||
| Line 1: | Line 1: | ||
| − | == | + | {| class="wikitable" style="margin: 1em auto 1em auto" |
| − | + | |+ MUST DO actions for Ganymede | |
| − | + | ! Action !! Completion Date | |
| − | + | |- | |
| − | + | | The projects must work together. This means that one should be able to load any subset of the Ganymede projects into Eclipse and each of the loaded projects should be able to pass all the same tests as if it had been loaded independently. || ?? | |
| − | + | |- | |
| − | + | | Projects must have build process maturity and their own functional project update site - the Ganymede site will reference these sites, not replace them. || ?? | |
| − | + | |- | |
| − | + | | Projects must use 4-part [[Version Numbering|version numbers.]] || ?? | |
| − | + | |- | |
| − | + | | Any new (new during Ganymede) third-party plug-ins that are common between projects must be consumed via [http://www.eclipse.org/orbit/ Orbit]; the final Ganymede release will not have duplicate third-party libraries (note that this only applies to identical versions of the libraries; thus if project A requires foo.jar 1.6 and project B uses foo.jar 1.7, that's ok). || ?? | |
| − | + | |- | |
| − | + | | All plug-ins (bundles) must use the true bundle form. That is, provide a manifest.mf file, and not rely on the plugin.xml file being 'translated' into a manifest.mf file at initial startup. See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=130598 bug 130598]. || ?? | |
| − | + | |- | |
| − | + | | All plug-ins must correctly list their required JVM versions in the manifest.mf. See the wiki page about selecting the correct JVM [http://wiki.eclipse.org/index.php/EMF_2.3_JVM_Requirements#Runtime_.2F_Compilation_Compatibility]. || ?? | |
| − | + | |- | |
| − | + | | Project representatives must attend the planning meetings and conference calls - you have to be involved to be involved. A few misses are ok, but chronic lack of attendance is a no-no. || ?? | |
| − | + | |- | |
| − | + | | 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 from each project will provide communication channels: phone, mail, IM, IRC and will be available during ''to-be-specified'' crucial integration times || ?? | |
| + | |- | ||
| + | | Projects must have stated and demonstrated their intent to join Ganymede by the M4+0 date. Projects do so by adding themselves to the table/list above and to the Ganymede common build infrastructure. || ?? | ||
| + | |- | ||
| + | | Projects must have a written ramp down policy by M6+0. (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. Here [http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/eclipse-project-home/plans/3_2/freeze_plan_3.2.html] is the Platform 3.2 ramp down policy as a guideline for other projects.) || ?? | ||
| + | |- | ||
| + | | Projects must have their IP approved (a normal Eclipse requirement) and will follow the Eclipse Legal deadlines to do so. || ?? | ||
| + | |- | ||
| + | | Projects must [[Update_Site_Optimization | optimize ]] their update site using [[Pack200 | pack200 ]] to reduce bandwidth utilization and provide a better update experience for users. Additionally, they should do site digesting. || ?? | ||
| + | |- | ||
| + | | Projects must use signed plugins using the Eclipse certificate. Exceptions authorized by the planning council for technical reasons. || ?? | ||
| + | |- | ||
| + | | Projects must have use jar'ed plug-ins unless there are technical reasons. || ?? | ||
| + | |- | ||
| + | | Projects must use Eclipse message bundles unless there are technical reasons not to. (see [[Message Bundle Conversion Tool]] and [http://www.eclipse.org/eclipse/platform-core/documents/3.1/message_bundles.html]) | ||
| + | |} | ||
Revision as of 10:21, 20 February 2008
| Action | Completion Date |
|---|---|
| The projects must work together. This means that one should be able to load any subset of the Ganymede projects into Eclipse and each of the loaded projects should be able to pass all the same tests as if it had been loaded independently. | ?? |
| Projects must have build process maturity and their own functional project update site - the Ganymede site will reference these sites, not replace them. | ?? |
| Projects must use 4-part version numbers. | ?? |
| Any new (new during Ganymede) third-party plug-ins that are common between projects must be consumed via Orbit; the final Ganymede release will not have duplicate third-party libraries (note that this only applies to identical versions of the libraries; thus if project A requires foo.jar 1.6 and project B uses foo.jar 1.7, that's ok). | ?? |
| All plug-ins (bundles) must use the true bundle form. That is, provide a manifest.mf file, and not rely on the plugin.xml file being 'translated' into a manifest.mf file at initial startup. See bug 130598. | ?? |
| All plug-ins must correctly list their required JVM versions in the manifest.mf. See the wiki page about selecting the correct JVM [1]. | ?? |
| Project representatives must attend the planning meetings and conference calls - you have to be involved to be involved. A few misses are ok, but chronic lack of attendance is a no-no. | ?? |
| 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 from each project will provide communication channels: phone, mail, IM, IRC and will be available during to-be-specified crucial integration times | ?? |
| Projects must have stated and demonstrated their intent to join Ganymede by the M4+0 date. Projects do so by adding themselves to the table/list above and to the Ganymede common build infrastructure. | ?? |
| Projects must have a written ramp down policy by M6+0. (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. Here [2] is the Platform 3.2 ramp down policy as a guideline for other projects.) | ?? |
| Projects must have their IP approved (a normal Eclipse requirement) and will follow the Eclipse Legal deadlines to do so. | ?? |
| Projects must optimize their update site using pack200 to reduce bandwidth utilization and provide a better update experience for users. Additionally, they should do site digesting. | ?? |
| Projects must use signed plugins using the Eclipse certificate. Exceptions authorized by the planning council for technical reasons. | ?? |
| Projects must have use jar'ed plug-ins unless there are technical reasons. | ?? |
| Projects must use Eclipse message bundles unless there are technical reasons not to. (see Message Bundle Conversion Tool and [3]) |