| <!-- saved from url=(0022)http://internet.e-mail --> |
| <html> |
| |
| <head> |
| <meta http-equiv="Content-Language" content="en-us"> |
| <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> |
| <meta name="GENERATOR" content="Microsoft FrontPage 4.0"> |
| <meta name="ProgId" content="FrontPage.Editor.Document"> |
| <meta name="Author" content="Eclipse Project PMC"> |
| <title>Why Eclipse 3</title> |
| <link rel="stylesheet" href="../../default_style.css" type="text/css"> |
| </head> |
| |
| <body> |
| |
| <h1>Why Eclipse "3.0"?</h1> |
| <p>We're changing the designation of the next Eclipse release to 3.0 from 2.2. |
| This note explain why, and what it means to you.</p> |
| <blockquote> |
| <p><a href="#why3">Why is the next release of Eclipse called 3.0 rather than |
| 2.2?</a><br> |
| <a href="#API">Does this mean that Eclipse APIs will be changing in incompatible |
| ways?</a> <br> |
| <a href="#plugins">Does this mean that plug-ins based on Eclipse 2.0 and 2.1 |
| will not work in 3.0?</a> <br> |
| <a href="#much">Will a lot of the Eclipse APIs be changing?</a> <br> |
| <a href="#whynow">Why break compatibility now?</a> <br> |
| <a href="#which">Which APIs will changed for 3.0?</a> <br> |
| <a href="#when">When will breaking API changes be made?</a> <br> |
| <a href="#whodecides">How do we decide whether a breaking change goes in?</a> |
| <br> |
| <a href="#forteams">What does this change mean for teams working on 3.0?</a> |
| <br> |
| <a href="#forcusts">What does this change mean for customers waiting for 3.0?</a> |
| <br> |
| <a href="#forproducts">What does this mean for products shipping on 2.1?</a> |
| </p> |
| </blockquote> |
| <h3><a name="why3"></a>Why is the next release of Eclipse called 3.0 rather than |
| 2.2?</h3> |
| <p>For the next Eclipse release we are planning both consolidation and major new |
| functionality. Some of the changes that we are considering would require us |
| to break compatibility with existing plug-ins. Incrementing the minor version |
| number from "2.1" to "2.2" suggested that all existing 2.* |
| plug-ins would run on the new release without change. Changing the major version |
| number from "2" to "3" suggests that existing 2.* plug-ins |
| do not work with the new release, and would need to be ported to 3.0. This gives |
| the development team more maneuvering room and more accurately sets expectations.</p> |
| <h3><a name="API"></a>Does this mean that Eclipse APIs will be changing in incompatible |
| ways?</h3> |
| <p>Yes. Some of the Eclipse APIs will likely change in ways that will require |
| rewriting portions of existing plug-ins written to the 2.* APIs. Most of the |
| Eclipse APIs will remain the same.</p> |
| <h3><a name="plugins"></a>Does this mean that plug-ins based on Eclipse 2.0 and |
| 2.1 will not work in 3.0?</h3> |
| <p>Yes. The changes to the Eclipse APIs in 3.0 will mean that existing 2.1 (and |
| 2.0) plug-ins will not work with Eclipse 3.0. Developers of 2.1 plug-ins will |
| need to port them to 3.0, and ship new versions of their plug-ins.</p> |
| <h3><a name="much"></a>Will a lot of the Eclipse APIs be changing?</h3> |
| <p>No. Most of the Eclipse APIs will be the same in 3.0 as in 2.1. In general, |
| we are satisfied with the state of all Eclipse APIs in 2.1 and have no inclination |
| (or time) to start over. We would only break APIs in 3.0 when have a compelling |
| case for doing so. And when we find we need to break APIs, we would do it in |
| a controlled way that minimizes the effort required to port an existing plug-in |
| to the 3.0 APIs. We are not interested in breaking APIs willy-nilly.</p> |
| <h3><a name="whynow"></a>Why break compatibility now?</h3> |
| <p>Maintaining compatibility incurs a cost by stifling radical improvements and |
| making it hard to outgrow past mistakes. Breaking compatibility incurs a cost |
| because it generally makes life more difficult for plug-in tool authors and |
| customers alike. Some of the improvements under consideration are difficult |
| to pursue while maintaining compatibility. For instance, changing Eclipse so |
| that it can be used as a rich-client platform will almost certainly require |
| breaking API changes to decouple the workbench UI from workspace and resources |
| and parcel up workspace-free functionality into new plug-ins. The freedom to |
| break compatibility gives us additional freedom to innovate and make the next |
| Eclipse significantly better than it could have been had we tried to maintain |
| compatibility.</p> |
| <h3><a name="which"></a>Which APIs will changed for 3.0?</h3> |
| <p>We don't know which APIs will change at this point. We plan to provide a comprehensive |
| <i>Eclipse 3.0 Porting Guide</i> that covers all areas where we've made breaking |
| API changes, and describes how to port existing 2.1 plug-ins to 3.0. Up-to-date |
| drafts of the <i>Eclipse 3.0 Porting Guide</i> will be included with each milestone |
| build so that it's possible to climb aboard the 3.0 release wagon at the early |
| stages, or to estimate the amount of effort that will be involved in eventually |
| porting existing plug-ins to 3.0.</p> |
| <h3><a name="when"></a>When will breaking API changes be made?</h3> |
| <p>Since breaking API changes also destabilize the development of 3.0, we plan |
| to make all breaking API changes early in the cycle. We plan to make the breaking |
| API changes in batches so that for our internal development we do not get into |
| a constant API catch-up mode. By the end of calendar year 2003 (milestone M5), |
| all breaking API changes will be in place and tested. This will allow the remainder |
| of the 3.0 release cycle to proceed without further disruption, and allow existing |
| plug-ins to be ported to the new 3.0 APIs in parallel.</p> |
| <h3><a name="whodecides"></a>How do we decide whether a breaking change goes in?</h3> |
| All breaking API changes will be reviewed by the Eclipse development team leads |
| and the Eclipse Project PMC to ensure that there is a sound case for breaking |
| compatibility on certain APIs, and that the breakage is minimized. The appropriate |
| section for the Eclipse 3.0 Porting Guide will show how to rewrite affected code |
| to work with the new APIs. |
| <h3><a name="forteams"></a>What does this change mean for teams working on 3.0?</h3> |
| This is a golden opportunity to address some big problems. Go for it! |
| <h3><a name="forcusts"></a>What does this change mean for customers waiting for |
| 3.0?</h3> |
| <p>Sit tight and don't worry. Wherever we end up, we'll show you how to get |
| there from here.</p> |
| <h3><a name="forproducts"></a>What does this mean for products shipping on 2.1?</h3> |
| <p>Nothing has changed. Eclipse 2.1 is the most up-to-date stable base for Eclipse |
| plug-ins and products. We will continue to fix significant defects in this code |
| base, and issue fixes as patches and as periodic 2.1.* maintenance releases. |
| </p> |
| </body> |
| |
| </html> |