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...)
Thanks, and congratulations!
-walter
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
;)
John
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? Doug. From: eclipse-dev-bounces@xxxxxxxxxxx
[mailto:eclipse-dev-bounces@xxxxxxxxxxx]
On Behalf Of Ian Bull Sent: Saturday, April 17, 2010 1:01
PM To: E4 Project developer mailing list Cc: eclipse-dev@xxxxxxxxxxx Subject:
[eclipse-dev] Re: [e4-dev] Eclipse Project 4.0 Release 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.
cheers, ian
On Fri, Apr 16, 2010 at 11:59 AM, John Arthorne <John_Arthorne@xxxxxxxxxx> wrote:
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.
[1]
http://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_0.xml
The
Eclipse PMC _______________________________________________ e4-dev mailing
list e4-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/e4-dev
-- R. Ian Bull |
EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource_______________________________________________ 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
|