Yes, I think the biggest challenge we will face is managing expectations. While this is 1.0 technology, for a lot of users they will see this as 4.0 technology -- and what's written in our plans will have little bearing on them.
I'm not opposed to calling this Eclipse 4.0 as we need to make that leap, we just need to make sure we manage it well.
On a related note, KDE went through this exact same thing a few years back (oddly enough with their 4.0 release too). I don't remember the details (funny, that was the time I stopped using KDE), but a quick google search brought up this article:
I agree we need to be very careful to explain the expectation and
limitations of 4.0. For one, I would not expect to see 4.0 available
from the main eclipse.org/downloads page but from another page. I
think it is also very important we can answer the 'install new
software? question that Walter raises.
Maybe what we should have an Eclipse 4.0 end user landing page that is
focused on the download and expectation setting experience?
Ian
On 4/19/2010 12:25 PM, Walter Harley wrote:
I am not so concerned by
adoption in products as I am by adoption by naive users. The version
increment will confuse some people who are just trying to download
whatever the latest & greatest is in order to learn Eclipse. We
need to make it very clear, on all the download pages, what the
functionality and status is.
Specifically, since we've been
training users that it's okay to install a base package of Eclipse and
then install additional features after the fact with P2, we need to
state what Eclipse functionality is not yet available for 4.0.
Otherwise we'll be fielding lots of newsgroup questions along the lines
of "I installed 4.0 but when I go to install software, it doesn't show
any Java tools. Is the website broken?"
(I spend enough of my time just
helping user N+1 discover that the Windows zip utility is unreliable
and that a JRE is required...)
I think Eclipse SDK 4.0 is the most logical name. It is important we
have a stable release so people will start to experiment and
investigate. I agree that it without the rest of the Eclipse stack
the appeal for adoption will be marginal.
On 4/19/2010 11:03 AM, John Arthorne wrote:
I think regardless of the name
or the quality of the release, it won't be widely adopted in products
until it is part of the release train. You will be able to run the
base SDK, but without the rest of the Eclipse stack and the EPP
packages it will have limited appeal. As for the name, are you
suggesting that we just don't give the release a traditional version
number? From past discussions on release names it seems people really
like having version numbers so they can keep all the releases straight.
So, given that it contains major changes and comes after 3.6, the
number 4.0 seems like the only logical version number for it.
Besides, we need to start
incrementing our release version numbers so we can catch up to CDT ;)
I have to admit I’m
surprised by the numbering. Calling it 4.0 signals that it’s ready to
deploy into product. Are you saying it’s ready for that? Or should it
be called something like a super-milestone, or preview, or alpha?
This is very exciting,
thanks for the update John!
I have two questions about this.
First, have any of the Eclipse 3.x platform bundles changed in the 4.0
SDK? If they have, what version numbers (and update descriptors) are
they using? I'm wondering if we can install Helios and "upgrade" to
the 4.0 SDK, and then use the 3.x update sites for the PDE/JDT/Platform
updates? Or, once you go to the 4.0 SDK will you be required to use
the 4.0 update sites for everything? -- Maybe it's a little too early
to try this yet.
Secondly, what should we (Eclipse committers) be telling people about
Eclipse 4.0? Obviously there are lots of people who simply use Eclipse
as their IDE of choice. Are the plans to produce EPP packages for
Eclipse 4.0? I imagine that when we release Eclipse 3.6 and a month
later release Eclipse 4.0, there will be some confusion among users
regarding what version they should use. From what I can tell, it
appears that there will be very few "end user features" in Eclipse 4.0.
However, I don't want to discourage people from using it if it's the
intended upgrade path (Install 3.6 and upgrade to 4.0 in July).
Again, this is awesome! I'm been following the e4 lists for at least 2
years now and it's really exciting to see all this work come together.
Congratulations to everyone involved.
For the past eight months we have been working towards a July 2010
release tentatively called the e4 1.0 release. One of the major goals
of this release was to bring the e4 technology delivered in our July
2009 "0.9" release up to a level of maturity and stability that we
could run the Eclipse platform and its ecosystem of plug-ins on top of
it. As a community we have been referring to this combination of the
existing Eclipse platform with e4 technology as "Eclipse 4.0".
Last week we began building the full Eclipse 4.0 SDK, and delivered it
as part of our M5 milestone. This build combines some e4 components,
the e4 compatibility layer, and the Eclipse project 3.6 SDK. With this
milestone it is time to switch emphasis from incubating e4 work to
focus on graduating, polishing, and delivering this Eclipse 4.0 SDK.
Since this combined release incorporates plug-ins from several Eclipse
sub-projects, it would be incorrect to call it an e4 release. To
reflect this reality, and our primary emphasis on the Eclipse 4.0 SDK
deliverable, the Eclipse project PMC has decided to take the following
steps:
- We will no longer refer to the "e4 1.0 release" in our plans and
downloads after M5. We will instead call our July 2010 release the
"Eclipse SDK 4.0" release. This deliverable will combine components
from the Eclipse Platform, JDT, PDE, Equinox, ECF, and EMF out of the
Helios release, with the e4 components required to build the Eclipse
4.0 SDK.
- CSS Styling, Modeled Workbench, and some of the core e4 programming
model infrastructure have matured in e4 and will move into the Eclipse
Platform project prior to the July release. This new technology allows
building the Eclipse 4.0 SDK on top of it, which thus only depends on
graduated components.
- e4 _javascript_ tooling has been moved to the JSDT project under the
Webtools top-level project.
- Other components such as SWT Browser Edition, _javascript_ modularity,
XWT, Toolkit Model, Bespin Server, and the new e4 resources work around
semantic file systems are going to remain in the e4 incubator for now.
These components have not reached the level of stability and community
required for graduation into a mature project. We will continue to
evaluate whether more components should graduate either in this release
or later releases, based on their progress and adoption.
- The e4 components that remain in the incubator will release
simultaneously with the Eclipse top-level project's 4.0 release, and
will be available in a separate release repository, much like the
Helios repository and EPP packages incorporate both incubating and
mature components in a single release. Since we intend to keep the e4
project as a perpetual incubator, it doesn't make sense to attach a
traditional version number to the incubating e4 portion of the release.
Where necessary, we will refer to the e4 incubator portion as the "e4
July 2010" downloads (for example on the e4 downloads page). Version
numbers of individual e4 plug-ins will evolve according to the Eclipse
project's standard version numbering guidelines.
- We will continue running e4 incubator builds throughout the July 2010
release cycle (and beyond). In addition we will run Eclipse project 4.0
stream builds. Until the Eclipse project Helios release is completed,
we will run these 4.0 stream builds out of the "R4_HEAD" branch of the
Eclipse project repository. Note that the vast majority of plug-ins
don't require branching, and will be consumed directly from the "R3.6"
version tag produced by the Helios release.
A draft plan of the Eclipse Project 4.0 release is now available [1].
This plan is quite similar to our previous e4 plan, with the same
milestones and timeline, and most of the same plan items.
