I'll just concur with Ed's remarks.
I think you should just pick one version to put in the release train, and
ship the other version separately. There is nothing preventing your project
from producing two releases around the same time, but including multiple
versions in the release train is just going to cause confusion. If you
have downstream consumers within the release train you'll need to figure
out if they can handle the migration to your new API in time for Helios.
If they can, you can include the new version in the release train and release
1.4 separately for the clients who need it. p2 is just enforcing the "singleton:=true"
directive in your bundle manifest and is behaving correctly here; if multiple
versions were installed the framework would be forced to pick one of them
and ignore the other.
Ed Merks <ed.merks@xxxxxxxxx> Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
12/01/2009 06:50 AM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Re: [cross-project-issues-dev] Concurrent
support for old and new APIs.
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
> but different version.
I wouldn't characterize this as a failure. For bundles that must
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
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
> 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
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
cross-project-issues-dev mailing list