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

Eclipse4/SR1Plan

< Eclipse4
Revision as of 10:23, 6 June 2012 by Emoffatt.ca.ibm.com (Talk | contribs) (Formal API specifications)

Eclipse 4.2 SR1 Plan

The goal is to plan out what we can do for SR1. We should be trying to limit the amount of work that we commit to here because there's only a short time in which to work and we have to take into account that it's summer and many of us will be taking vacation and / or will only be working 4 days / week for July.

Deliverables

Bug fixes

We should go over the current list of defects and make sure that we're only attempting to address significant defects. Also we should expect that we will be receiving some good ones from the community that we'll have to address The work for making sure that BiDi and accessibility are OK go into this bucket but are non-negotiable in the sense that this work has already been committed to.

Formal API specifications

This breaks down into 4 basic areas; UI Model, CSS, DI and Services as well as two main activities that have to be done for each area; documentation and refactoring.

The first pass should be to define the scope of the API so that we spend our time documenting and refactoring only those things that we are sure should be API (note that we can likely defer things that are on the fence as 'provisional', giving us the 4.3 cycle to finalize their status).

UI Model Documentation

The EMF model should be updated with the basic documentation of types and fields...we'll likely also want to re-package the generated documentation to wherever we put the general documentation.

We also need to provide some general documentation on why the model is structured as it is and on how to manipulate it to get various useful results.

Pictures would be nice :-)

The we need documentation of the relationship between the model, the rendering engine and its associated renderers. This should also explain the various rendering specific tags as well as some of the utilities (CSSRenderingUtils...).

Things to look into:

- We should make the 'visible' attribute provisional in anticipation of changing its name to something less confusing in 4.3.

- We should examine the Commands side of the model to see if it can be simplified. Note that for 4.2.1 this simply means marking the classes that we think we can get rid of as 'provisional' (or 'deprecated' if we're confidant that it'll go away).

CSS Documentation

DI Documentation

Services Documentation

Back to the top