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

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

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.

John

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

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

John,
 
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.
 
Ian

---

From: eclipse-dev-bounces@xxxxxxxxxxx
[mailto:eclipse-dev-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent: November 8, 2006 12:04 PM
To: General development mailing list of the Eclipse project.
Subject: 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)

John

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>

To	eclipse-dev@xxxxxxxxxxx
cc
Subject	[eclipse-dev] Planning Meeting Notes - Nov 8, 2006

 

------------ 
Discussion 
------------ 

Workspace: 
- 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. 

---------- 
Outreach 
---------- 

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

Platform/JDT Text: 
- interview together with the Zurich team for the Eclipse Magazine:
 - http://www.eclipsemag.net

-------- 
Status 
-------- 

Platform UI: 
- XSLT: 
 - 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

JDT UI: 
- 3.3M3 testing and shipping
- preparing 5 year Eclipse anniversary presentation
- bugfixing: 
 - improved presentation and filtering of derived resources in refactoring
   preview 
 - 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 

Runtime: 
- 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 

Debug: 
- M3 test pass 
- bug fixing 
- M4 planning 

PDE: 
- 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
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev