[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse-dev] Re: [e4-dev] Eclipse Project 4.0 Release
|
Hi John,
these are great thoughts and referencs.
The one thing I'm not so sure about is whether "The main "distro" for Eclipse is the annual simultaneous release
and the EPP packages."
For sure
there's ever increasing number of Linux Distros such as Fedora picking up the Eclipse SDK (thanks to Andrew
Overholt and the Linux Distros project).
Second, there's the commercial packagers like EclipseSource
/ Yoxos, Pulse, MyEclipse and others.
But at least it looks like the number of such tier 1
distros is manageable, and perhaps according to your findings, briefing those
tier 1 distros is among the most important things to be
done.
Talking about the importance of version numbers, and taking
the Linux Kernel version numbering scheme into account, what about a "4.0pre"
number?
Thanks,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
direct
+43.662.457915.85 fax +43.662.457915.6
Thanks for the pointer Ian, that was
a very interesting article about the KDE 4 experience. Exploring in more detail,
I also found a detailed analysis from the development team's perspective on
Groklaw that made for interesting reading [1]. I certainly see some parallels
here to the planned Eclipse project 4.0 release, in that the KDE 4.0 release was
primarily targetting developers, with the idea that they would adopt and help
evolve the technology into a future release oriented more at end users. For
frameworks like KDE and Eclipse platform, with big technology stacks built on
top of them, it takes a long time to percolate major technology changes through
all those layers. In the open source world, having releases is the main
mechanism for getting that adoption process started. The trick is in how to get
that release out to the developers who want to start building on it, without end
users picking up the initial wave of that adoption process and expecting
something more polished.
Comparing
more closely with KDE, I think there are some important differences between the
two releases that will help us to avoid problems. First, the Eclipse project 4.0
just isn't as big of a technology change. To put it in perspective, there is
only one plug-in out of nearly 200 in the 3.6 stream of the Eclipse SDK that has
been forked in the 4.x stream so far. Almost the entire classic Eclipse SDK is
running without any code changes on top of this new branch. We certainly have
lots of bugs to iron out, but the important thing is that we are able to fix
those bugs without changing anybody else's code. This bodes well for the
prospect of the rest of the Eclipse technology stack to adopt this new
technology without major disruption. Second, in KDE there is a big split between
the distros that deliver the technology to end users and the project that
produces it. A lot of the analysis suggests that the problems with KDE were
exacerbated by distros hastily packaging and delivering the technology to end
users, which is not what the KDE development team was expecting. With Eclipse I
think there isn't such a big split between technology builders and packagers.
The main "distro" for Eclipse is the annual simultaneous release and the EPP
packages. As an Eclipse community we can more carefully control that channel and
make sure we only put solid, polished functionality out there each year. The
platform 4.x stream will only make it into a simultaneous release when it meets
that higher bar of solid end user functionality and close integration and
adoption by other Eclipse projects.
The interesting thing about the KDE experience is how important the
version numbers turned out to be in setting expectations about the release. It
seems they actively put the message out that it was a developer release, but
distros and end users picked it up because the 3.x stream immediately seemed
like old, legacy technology once that 4.x release came out. This perception
probably comes from the commercial software world, where version numbers are
primarily a statement about features, and version x.0 implies big new features
over the x-1 release. In the world of open source frameworks, I think of version
x.0 primarily meaning "not fully compatible with version x-1", for some
definition of compatibility that varies according to project. Thus to my mind
this isn't a signal to immediately jump on it and abandon the old technology
stream. Under this interpretation, using a version of 3.99 for our July release
would actually greatly increase expectations about the level of stability and
compatibility, since our consumers expect near perfect compatibility in the 3.x
stream.
Unfortunately, what we as
the project developers think the version number means won't help if the wider
consumer community and media have different expectations. It's clearly important
that we get the message out about what this release means, who its audience is,
and what developers and end users should expect from it. This is something we're
going to continue thinking about, and I'm sure there will be many conversations
going on about this over the coming weeks. I'm glad that these questions have
come up now and we are having a public discussion about it while there is still
time to make adjustments.
John
[1]
http://www.groklaw.net/article.php?story=20080710131440951
Ian Bull
<irbull@xxxxxxxxxxxxxxxxx>
Sent by: eclipse-dev-bounces@xxxxxxxxxxx
04/19/2010 01:44 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
|
|
|
Subject
| Re: [eclipse-dev] Re: [e4-dev]
Eclipse Project 4.0 Release |
|
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:
http://www.linux.com/archive/feature/141769
cheers,
ian
On Mon, Apr 19, 2010 at 10:21 AM, Ian Skerrett <ian.skerrett@xxxxxxxxxxx> wrote:
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...)
Thanks, and
congratulations!
-walter
From: eclipse-dev-bounces@xxxxxxxxxxx [mailto:eclipse-dev-bounces@xxxxxxxxxxx] On Behalf Of Ian Skerrett
Sent: Monday, April 19, 2010
8:22 AM
To: eclipse-dev@xxxxxxxxxxx
Subject: Re: [eclipse-dev] Re: [e4-dev] Eclipse Project 4.0
Release
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
_______________________________________________
