|Re: [cross-project-issues-dev] Concurrent support for old and new APIs.|
Ed, Comments below. Ed Willink wrote:
Are these version numbers of the features? I'm not sure how it was valid for a 1.3 to contain a 2.0...HiThe 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.]
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?
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.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.
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.
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.Are we wrong to try to provide API compatibility in an alternate release?
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.Is there a better solution?
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
Back to the top