|
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.
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.
|
