Why is the next release of Eclipse called 3.0 rather than
2.2?

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.

Does this mean that Eclipse APIs will be changing in incompatible
ways?

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.

Does this mean that plug-ins based on Eclipse 2.0 and
2.1 will not work in 3.0?

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.

Will a lot of the Eclipse APIs be changing?

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.

Why break compatibility now?

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.

Which APIs will changed for 3.0?

We don't know which APIs will change at this point. We plan to provide a comprehensive
Eclipse 3.0 Porting Guide 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 Eclipse 3.0 Porting Guide 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.

When will breaking API changes be made?

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.

How do we decide whether a breaking change goes in?

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.

What does this change mean for teams working on 3.0?

This is a golden opportunity to address some big problems. Go for it!

What does this change mean for customers waiting for
3.0?

Sit tight and don't worry. Wherever we end up, we'll show you how to get
there from here.

What does this mean for products shipping on 2.1?

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.