Skip to main content

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


Comments below.

Ed Willink wrote:

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
I'll follow the bug to understand what's driving this...


       Ed Willink (on behalf of Alexander Igdalov)

cross-project-issues-dev mailing list

Back to the top