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.

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>

Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Re: [cross-project-issues-dev] Concurrent support for old and new        APIs.


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
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
cross-project-issues-dev mailing list

Back to the top