The joke I made at the summit to those sitting around me was that if we
break backwards compatability too badly our employers will pull our
funding. There was nervous laughter so I assume that meant there was
some truth to that :).
There was some discussion, but I think we were at the stage where we
wanted to brainstorm a bit without the straightjacket. But, yes, if we
do break backwards compatability too badly, it'll severely limit
adoptability of the new technology and could result in a fork. And no
one wants that (I hope...).
At any rate McQ relayed his confidence that we can do the cool stuff and
keep backwards compatability. It's obviously more work but necessary and
doable.
Cheers,
Doug.
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike
Milinkovich
Sent: Tuesday, June 24, 2008 2:50 PM
To: 'E4 developer list'
Subject: RE: [eclipse-incubator-e4-dev] CSS and declarative UI
round up
I am curious if there is a consensus around this point of
backwards compatibility. I understand that not achieving backwards
compatibility has negative ramifications for existing adopters. But
applying the straitjacket too tightly could mean that little to no
innovation can occur, which has even larger negative ramifications in
the long term.
Is there a consensus one way or another from the E4 team? I've
scanned the E4 Summit materials and did not see any explicit conclusion
on this point.
I am expecting that this effort will not undermine the existing
platform look & feel that SWT/JFace default to or break backwards
compatibility.
We have a lot of products built on this platform, backwards
compatibility is effectively mandatory.
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
