[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [eclipse-dev] Planning Meeting Notes - Nov 8, 2006

I think you might have misunderstood what I meant.  I wasn't suggesting that the Eclipse SDK would be called Callisto or Europa. I'm saying the release of the Eclipse SDK that ships next June would be called "The Europa release of Eclipse", just as there will be a "Europa release of Web Tools", "Europa release of Data Tools", etc.  In other words, it *is* the name of the event, not the name of the technology.  The number "3.3" has lost any useful meaning in describing release event because it is no longer tied to the version numbers of the plugins and features in that release.  

Our maintenance releases are a good example of the problem.  We have started working on the "3.2.2" maintenance release, but if you download this release and look at the plugins, you will see plugins numbered 3.2.0, 3.2.1, 3.2.2, 3.2.3, and many other numbers. So "3.2.2" is not really a useful description of that release. Meanwhile, the rest of the world just wants to know when the next Callisto update will arrive, they don't care what number is attached.  The same may become true of the release next June. If we decided that it was important to add some API in a maintenance release before next June (as some projects have already done), we would have to increase some plugin version numbers to "3.4" for the June 2007 release.  Thus Eclipse "3.3" would have some "3.3" and some "3.4" features inside it, which is just confusing for everyone.  To give another example, some plugins within the SDK may want to release more often - for example new releases of the compiler to coincide with Java language releases, or new releases of Equinox to coincide with new OSGi specification releases. They would be free to do so as long as they also produce a release next June to join the Europa train. Thus you could imagine Eclipse SDK 3.5 containing version 3.6 of the Java tools and version 3.8 of the OSGi implementation, etc. Just as a single version number cannot be applied to all projects shipping in the Europa release, there is no single version number that applies to all the components of the Eclipse SDK.

To give a final thought from a marketing perspective: if we follow our own version numbering guidelines, and we never make breaking API changes in the future, we will forever be stuck with "3.x" releases of the SDK.  How exciting does Eclipse 3.8 sound? It sounds like yet another series of minor changes to Eclipse version 3.  In reality, we believe each annual release has lots of exciting new features and technology, which is undershadowed by the "point release" label attached to it.


"Ian Skerrett" <ian.skerrett@xxxxxxxxxxx>
Sent by: eclipse-dev-bounces@xxxxxxxxxxx

08/11/2006 12:41 PM

Please respond to
"General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>

"'General development mailing list of the Eclipse project.'" <eclipse-dev@xxxxxxxxxxx>
"'Bjorn Freeman-Benson'" <bjorn.freeman-benson@xxxxxxxxxxx>
RE: [eclipse-dev] Planning Meeting Notes - Nov 8, 2006

I am not sure this is such a great idea.   First, Callisto and Europa are names that were created to reference a specific event, the release of multiple Eclipse projects.   It was not intended to identify a particular thing, project or technology.   Second, I donât think we want people to start calling the SDK,  Europa or Callisto, since this will start to weaken the Eclipse name.   In fact, we are actively trying to stop using the Callisto name, so if the SDK started having this in the splash screen it would be counter to this approach.
My preference is that you stick with version numbers to identify the SDK releases.

From: eclipse-dev-bounces@xxxxxxxxxxx [mailto:eclipse-dev-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
November 8, 2006 12:04 PM
General development mailing list of the Eclipse project.
Re: [eclipse-dev] Planning Meeting Notes - Nov 8, 2006


For those interested, the outcome of the discussion topic below is that we generally agree that adopting the Eclipse Foundation release naming is a good idea. I..e, begin referring to the next release of the Eclipse SDK as "Europa" rather than "3.3". This has absolutely no impact on the mechanics and version numbers of plugins and features. The most obvious place this will likely show up is in the Eclipse splash screen.  This actually brings us more in line with the rest of the world, who have consistently referred to the previous release as "Callisto" while we kept calling it "3.2". Discussion and comments from the community appreciated...

(And yes, we already know this will confuse some Austrians... https://bugs.eclipse.org/bugs/show_bug.cgi?id=147754#c10)


Mike Wilson/Ottawa/IBM@IBMCA
Sent by: eclipse-dev-bounces@xxxxxxxxxxx

08/11/2006 08:57 AM

Please respond to
"General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>

[eclipse-dev] Planning Meeting Notes - Nov 8, 2006






- Plugin version numbers no longer match the version we attach to the

release overall: Eclipse 3.2.2, Eclipse 3.3., etc.  Should we re-brand

our releases to avoid using these numbers? I.e., change our plans,

documentation, splash screen, etc, to refer to "Eclipse Callisto Fall

Update" or "Eclipse Europa" rather than numbers?  This would harmonize

with other Eclipse projects, and prevent the desire to "cheat" and align

our feature and plugin versions with a release number that has lost its

original meaning.



**** Happy Birthday, Eclipse! ****

Platform/JDT Text:

- interview together with the Zurich team for the Eclipse Magazine:

- http://www.eclipsemag.net



Platform UI:


- OSGi transformation

- M3 testing/verifying

- saving settings:

- configuration level settings

- sharing settings within a working set

- Windows Vista:

- testing

- commands:

- gathered feedback on menu API

- learning about menus

- investigating dynamic menus

- quick access:

- persisting selections

- search dialogs:

- bug fixing and refactoring in Resource dialogs

- preparing patch for JDT (Type dialogs)

- status handling & error dialog story:

- implementation

- preparing long talk abstract about Status Handling for EclipseCon

- viewers:

- looking at Debug's async tree viewer framework

- data binding:

- progress on observable map and tree


- 3.3M3 testing and shipping

- preparing 5 year Eclipse anniversary presentation

- bugfixing:

- improved presentation and filtering of derived resources in refactoring


- stale entries / wrong labels in open type dialog

- copy in call hierarchy

Platform/JDT Text:

- shipped 3.3 M3

- 3.3 M4 planning

- compiled wish list for JDT Core

- preparations for 5th Eclipse anniversary party

- inbox tracking


- contributed pde console view to pde/ui

- getting Orbit up and running

- added new bundles to Orbit from equinox-incubator

- preference work related to shared settings

- releasing lazy-start code

- splash screen work - prototype done for windows using JNI

- work on API tooling

- make Wassim's day by adding JAR signing to the builds

- Eclipse 3.3 M3 work

- bug triage and fixing


- M3 test pass

- bug fixing

- M4 planning


- filtered tree added to the plug-in registry view

- work continues on Ctrl+O support for the source pages of the

manifest editor

- considering tooling support for breaking plug-ns into smaller plug-ins

- 'Save As' implemented for both simple and composite cheat sheet editors

- cheat sheet creation workflow:

- adding support for automatically creating cheat sheet extension from

  the cheat sheet editor

- lots of bug fixes

- brian is on honeymoon

User Assistance:

- work continues on dynamic content support across the UA

- help model fully supports it, working on cheat sheets now

- work continues on the Ajax-based TOC tree view in the help web application
eclipse-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
eclipse-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit