John,
You are correct I did not
understand the original proposal. If I understand, you are
suggesting that each project involved in the Europa release would call their
release Europa, ex. Eclipse Europa Release, BIRT Europa Release, Web Tools
Europa Release,. This would essentially become a common identifier for
all projects that participated in the release but not trying to have the same
version number across all projects. Do I understand correctly? This
sounds like a reasonable idea.
It certainly seems tying the release
number to the plug-in version numbers is not working. I certainly agree that
the current numbering convention does make Eclipse 3.8 sound pretty lame. I’ve
actually been worried about this too. I can just hear our competitors
claiming that we have not released anything significant since we are still at a
3.x release.
That being said I am still a bit worried
about dropping a sequential identifier to the releases. Maybe it is
just me but here is what worries me.
1) For people on the outside, I think
sequential release numbers make it easier for them to understand what is the
latest and greatest. Remember we would be generating a new name
each year, so people on the outside would be forced to keep up with what is the
latest. If we were like Microsoft and only released every 5-7 years this
is certainly less of a concern.
2) Third party plug-in providers need to
identify which version of the Eclipse SDK they are compatible. Maybe it
is just me but I think saying XYZ plug-in is compatible with Eclipse 3.1, 3.2,
4.0 etc is just easier to understand than XYZ plug-in is compatible with
Callisto, Europa, next-Jupiter-moon-name-that-Bjorn-likes, etc.
3) I think for a global audience,
sequential numbers is much easier to translate and ensure we don’t
violate/confuse people in the translations. As you pointed out even
Europa was not really well received in Europe.
Calling something the Europa Fall and Europa Spring release might be a bit
confusing in Australia.
4) How you would name the actual zip file
and then further maintenance releases. For example, say some
project created their final build and it was made available for download, I
assume the zip file would have a name, maybe XYZProject-Europa.zip. Then
a really urgent critical bug came in and the release needed to be cracked open
and tweaked. I am assuming the file name would have to change. Would
this essentially start to create a version name based on the package number?
5) In general I really do believe people
expect and are sensitized to having a release numbers. If the SDK does
have one, it will just create confusion.
As a wild idea, why not just separate the
release number from the plug-in version. We are going into the
sixth year for the SDK, so why not just call it Eclipse 6. Next year call
the release Eclipse 7. We could also have all the projects identify
their Europa release. For example, WTP could be the WTP 2.0 Europa Release or
BIRT 2.2 Europa Release.
I do realize a lot of these things are
subjective and just opinions but I think that is what you were asking for.
Hopefully this will help generate some discussion.
Ian
From:
eclipse-dev-bounces@xxxxxxxxxxx [mailto:eclipse-dev-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent: November 8, 2006 1:59 PM
To: General
development mailing list of the Eclipse project.
Cc: 'Bjorn Freeman-Benson'
Subject: 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.
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
|