[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] Concurrent support for old and new APIs.
|
Ed,
Comments below.
Ed Willink wrote:
Hi
The MDT/OCL is making an API breaking change and so is taking a major
increment from 1.3.0 to 3.0.0 for Helios.
[The 2.0.0 is skipped since 1.3.0 already contained a 2.0.0 plugin.]
Are these version numbers of the features? I'm not sure how it was
valid for a 1.3 to contain a 2.0...
In order to preserve API compatibility for existing customers the
1.3.0 functionality for Galileo will be preserved in 1.4.0 for Helios.
By shipping two versions?
Initially we wanted to make most of the plugins in 1.4.0 and 3.0.0
have the same names but differ by bundle version only.
What about extension points and various other registrations? I imagine
the new extension point Kenn added for registering an OCL interpreter
for annotation-based constraints would get into the issue of which of
the two versions should register itself to handle OCL.
For instance there would be org.eclipse.ocl_1.4.0.qualifier.jar for
MDT OCL 1.4.0 and org.eclipse.ocl_3.0.0.qualifier.jar for MDT OCL
3.0.0. However, for the case when 1.4.0 and 3.0.0 are installed
together into the same target platform this seems not to be working.
This is so because p2 fails to install bundles that have the same name
but different version.
I wouldn't characterize this as a failure. For bundles that must be
singletons it should not allow you to install two active instances.
We therefore plan to rename the org.eclipse.ocl-based names to
ocl.eclipse.ocl20a to avoid the p2 problems. [20a represents the first
attempt to codify the Eclipse resolutions of OMG 2.0 specification
problems.]
That sounds exceedingly horrible.
Questions: Is it right to rename plugins and features (but not
packages or extension points)?
It doesn't sound good at all.
Is p2 at fault in forcing us to rename?
No, bundles with extensions or using extension points must be singletons.
Are we wrong to try to provide API compatibility in an alternate release?
No, but trying to ship both into Helios seems misguided. After all,
won't all downstream clients be faced with the same "I must ship two
versions" dilemma.
Is there a better solution?
I think breaking the API and simply expecting clients to live with it
seems the better approach. Clients wanting the old version should just
use the older version.
If you are able to help us please comment on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=293605.
I'll follow the bug to understand what's driving this...
Regards
Ed Willink (on behalf of Alexander Igdalov)
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
