Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Forward compatibility instead of backwards compatibility? (Re: what's next?)

This seems like a perfect discussion topic for the call tomorrow.

McQ.

Inactive hide details for Oleg Besedin---12/08/2009 11:38:19---The major part of the E4 effort has (and will be) centered on acOleg Besedin---12/08/2009 11:38:19---The major part of the E4 effort has (and will be) centered on achieving backward compatibility. That means that half the people


From:

Oleg Besedin/Ottawa/IBM@IBMCA

To:

E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>

Date:

12/08/2009 11:38

Subject:

[e4-dev] Forward compatibility instead of backwards compatibility? (Re: what's next?)





The major part of the E4 effort has (and will be) centered on achieving backward compatibility. That means that half the people, instead of working on new things, work on backward compatibility.
Can we ever make E4 smaller and simpler then 3.x while maintaining 3.x functionality? (And if we can, why not just do it in the 3.x stream?)

I think there is a solution to that. What if we consider introducing E4 as a runtime platform rather than the development platform?

Instead of:
Developer using E4 IDE -> to produce -> E4 RCP app
we consider:
Developer using 3.x IDE -> to produce -> E4 RCP app

In this vision, a developer would use the "classic" 3.x Eclipse IDE + extra E4 feature for his work. The E4 feature (in this vision, a part of Eclipse 3.x SDK):
- will support development of E4 RCP apps.
- will have code supporting E4 plugins to be run in 3.x IDE (to some degree).

What we get with this approach:
- backward compatibility becomes non-issue
- we can cut the tail for the deprecated functionality: immediately for new RCP apps; eventually for Eclipse plugins as they migrate from 3.x style to E4 style
- gradual development: we don't have to provide 100% functionality of the current Eclipse SDK in the original E4 release
- no disruption to users: rather than "switch or die" approach, people can continue to use 3.x and add E4-style plugins as they become available.

This all sounds too good to be true, I must be missing something somewhere :-).

Sincerely,
Oleg Besedin


Mike Wilson/Ottawa/IBM@IBMCA
Sent by: e4-dev-bounces@xxxxxxxxxxx

08/05/2009 09:06 AM

Please respond to
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
To
e4-dev@xxxxxxxxxxx
cc
Subject
[e4-dev] e4 call this week? what's next?




My sense is that a lot of people will be on vacation, and I'm booked into all day meetings on Thursday. Do we want to skip this call? Also, are we back on a bi-weekly schedule now that 0.9 is out?

--------

We've said all along that once 0.9 was released, we were going to do a review to decide where we are and what we should be focusing on. To help guide this, we should enumerate the open questions. Here's a starting list:

Q: What does the "pure" (i.e. without the compatibility layer) workbench look like?

Q: What components will go into Eclipse 4.0 (both from e4, and in terms of additional projects that need to be part of the SDK)?

Q: What components will go into Eclipse 3.6?

Q: How do we handle the workload?

This last question is, I believe, a critical one. There's nothing magic about this: there is a ton of work to be done, and if we can't get lots of people working on it, the result won't be very satisfying. For those of you who are already committing time, thank you; for those of you who are committers who haven't really made any contributions yet: what are you going to do to help?

McQ.
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev


GIF image

GIF image


Back to the top