[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [mdt-ocl.dev] Re: Backwards compatibility for MDT OCL
|
Hi Kenn and Ed,
+1 to Ed's explanation of the version choice.
As regards GMF dependency on MDT OCL 1.4.0, the quiestion is again in backwards compatibility. To be precise, there are some deviations in the current (1.3.0) implementation from the new OCL 2.2 standard which are visible to the end user. It should be easy to update the OCL scripts - still it requires some minimal effort. Consequently, GMF and other projects may decide to bifurcate their support for OCL. MDT OCL 1.4.0 gives them a chance to do so. However, I think downstream projects participating in Helios will prefer just to switch to the newest version of OCL because the impact on clients will probably be minimal.
Cheers,
Alex.
-----Original Message-----
From: mdt-ocl.dev-bounces@xxxxxxxxxxx [mailto:mdt-ocl.dev-bounces@xxxxxxxxxxx] On Behalf Of Ed Willink
Sent: Wednesday, July 22, 2009 11:03 PM
To: MDT OCL mailing list
Subject: Re: [mdt-ocl.dev] Re: Backwards compatibility for MDT OCL
Hi Kenn
Kenn Hussey wrote:
> Alex,
>
> I'm OK with the idea of producing two different versions of MDT OCL
> (we actually considered doing this for UML2 at one point), although,
> as Nick mentioned, the major version should probably be 2.0 instead of
> 3.0.
We would prefer 2.0, but we already have a 2.0 in Galileo for the UML binding plugin that had to have a major version increment to match UML's. Christian reasonably wanted to make clear that OCL had not had an API change so the other OCL plugins stayed at 1.x.
Having a mix of N and N+1 versions in the same release is confusing so moving direct to N+1 seems the least bad alternative.
>
> You want to make sure that it is possible for both versions to
> co-exist in the same environment. The fact that the Ecore packages
> will have different version numbers in their URIs will help, and
> assuming you're making use of content types instead of file extensions
> for serialized artifacts (are there any?) you should be OK. The one
> challenge I can think of is if/when major consumers of OCL, such as
> GMF, depend on one version vs. the other. This will, for example,
> force all GMF-based applications to use that particular version unless
> GMF in turn bifurcates its support for OCL...
The hope is that every project moves forwards. Ongoing 1.x is only for those that have a very stringent API concern or determination to preserve the particular set of ambiguity and contradiction resolutions that MDT-OCL 1.3.0 offers as a best endeavour support for OCL 2.0.
I would be very concerned if GMF felt any need to stay with 1.x, since I would be very surprised if any GMF user is unhappy with the very minor semantic improvements in OCL 2.2.
Do we need to change the version? see separate thread.
>
> Cheers,
>
> Kenn
>
> On Wed, Jul 22, 2009 at 5:18 AM, Alexander Igdalov
> <Alexander.Igdalov@xxxxxxxxxxx <mailto:Alexander.Igdalov@xxxxxxxxxxx>>
> wrote:
>
> Hi Kenn and Nick,
>
> The MDT OCL team has decided to implement the new OCL standard
> (2.2) and also to support backwards compatibility with the current
> implementation of the OCL 2.0 standard. Since the new and the old
> OCL standards are not compatible we have decided to create two
> initially similar sets of plugins/features - MDT OCL 1.4.0 (for
> backwards compatibility in Helios+ releases) and MDT OCL 3.0.0
> (the new implementation of OCL 2.2). We think it would be
> convenient to make a CVS branch for 1.4.0, and thus, to build
> 3.0.0 artefacts from HEAD and release 1.4.0 artefacts from the branch.
> Plugins for 1.4.0 and 3.0.0 are to be independent and must
> successfully co-exist in Helios. Ideally, 1.4.0 and 3.0.0
> plugins should be in different components - so that the users have
> the option not only to install both implementations but also to
> install only one of them.
> Kenn, is it ok for MDT OCL to split into two components?
> Nick, do you forsee any difficulties in releng (releasing 3.0.0
> from HEAD and 1.4.0 from branch)?
>
> Thanks,
> Alex.
>
>
> ----------------------------------------------------------------------
> --
>
> _______________________________________________
> mdt-ocl.dev mailing list
> mdt-ocl.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
>
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
