Skip to main content
[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

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

Back to the top