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.
Why is the next release of Eclipse called 3.0 rather than 2.2?
Does this mean that Eclipse APIs will be changing in incompatible ways?
Does this mean that plug-ins based on Eclipse 2.0 and 2.1 will not work in 3.0?
Will a lot of the Eclipse APIs be changing?
Why break compatibility now?
Which APIs will changed for 3.0?
When will breaking API changes be made?
How do we decide whether a breaking change goes in?
What does this change mean for teams working on 3.0?
What does this change mean for customers waiting for 3.0?
What does this mean for products shipping on 2.1?
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.
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.
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.
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.
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.
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.
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.
Sit tight and don't worry. Wherever we end up, we'll show you how to get there from here.
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.