Eric,
The only thing that jumps to mind is the addition of EObject.eInvoke,
but that's wasn't a breaking API change, except for those who ignored
the following documented constraint:
Implementations of EObject should extend |BasicEObjectImpl
<eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.eclipse.emf.ecore%7BEObject.java%E2%98%83EObject%E2%98%82org.eclipse.emf.ecore.impl.BasicEObjectImpl>|
or one of its derived classes because methods can and will be added
to this API.
Even in cases where this constraint is violated, it's really more of a
source incompatibility than a binary incompatibility, because nothing
else in the framework itself relies on calling this new method. As
such, I imagine you can use the latest EMF even with binaries compiled
against EMF 1.0.
Cheers,
Ed
On 05/01/2012 10:19 PM, Eric Moffatt wrote:
Last year we were looking into running an existing product on top of
Eclipse 4 and ran into a 'breaking API change'. As I remember it the
change was known and intentional (introduced in mid-Indigo) but I
can't seem to track down what it actually was and what its
implications would be...could someone point me towards whatever
information is available ?
Thanks in advance,
Eric
_______________________________________________
emf-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/emf-dev
_______________________________________________
emf-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/emf-dev
