<!-- 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> |