Re: [eclipse-dev] Re: [e4-dev] Eclipse Project 4.0 Release

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

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

"Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>
Sent by: eclipse-dev-bounces@xxxxxxxxxxx

04/18/2010 02:43 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>, "E4 Project developer mailing list" <e4-dev@xxxxxxxxxxx>
cc
Subject	RE: [eclipse-dev] Re: [e4-dev] Eclipse Project 4.0 Release

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
_______________________________________________