Hi Adolfo and Ed,
Adolfo, I agree with your description of MDT OCL 1.4.0 and
2.0.0.
I also hope it is possible to practically implement this
idea. Different versions of several plugins peacefully co-exist in Galileo, e.g.
javax.wsdl 1.5.1 and 1.6.2. There are projects which depend on the earlier
version of the plugin while others depend on the newer.
Best,
Aelx.
From:
mdt-ocl.dev-bounces@xxxxxxxxxxx [mailto:mdt-ocl.dev-bounces@xxxxxxxxxxx] On
Behalf Of Adolfo Sanchez-Barbudo Herrera Sent: Friday, July 17,
2009 5:36 PM To: MDT OCL mailing list Subject: Re: HA:
[mdt-ocl.dev] Compatibility Support
Hi Ed,
As far as I have understood 1.4.0 is intended to be
shipped in Helios as a version of the current status of MDT-OCL as a (probably
incorrect, incomplete, etc) implementation of the OCL 2.0 specification. The
efforts needed could be updating dependencies and solving any issue arisen from
changes in the dependent projects (EMF, UML, ...). Therefore, any actual MDT-OCL
client could perfectly fit in Helios release, without any backward compatibility
problem.
If clients want to align with the OCL 2.2 specification and/or
take advantage of any new feature or enhancement introduced in Helios, they will
have to move on the MDT-OCL 2.0.0. We will be mainly focused on this
release....
Again, I have some doubts about if this, which seems to be
conceptually sensible, can be done in the practice.... which would need some
help from a releng expert (yeah, Nick could add a valuable point of
view).
Cheers, Adolfo.
Ed Willink escribió:
When I wrote:
If the sole purpose of 1.4.0 is to provide a
slightly more confidence inspiring name than 1.3.3 for Helios then I have no
problem with someone doing that. I just don't have time to contribute to any
problems that arise as a result. If the intention is to offer more than
maintenance functionality in 3.3 please elaborate.
I think we should
proceed with OCL 2.2 as far as we can understand it on MDT-OCL 2.0.0 and
address any real compatibility issues as they arise.
I
was trying to find out what option A means. I would still like to know what is
planned for inclusion in 1.4.0, for which I provided my best guess above.
(Alex's original proposal discussed the practicalities of A/B but did not
discuss content.)
In the above I was sort of suggesting that perhaps
we do both A and B since there may not really be very much difference.
Moving to a vote is not very helpful, because I certainly do not
understand what we are actually voting on. We will only have another
discussion later on as to what the result of the vote meant.
Regards
Ed Willink
_______________________________________________ mdt-ocl.dev
mailing list mdt-ocl.dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
|