[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: HA: [mdt-ocl.dev] Compatibility Support
|
Hi all,
It's great that we are agreed. My +1 to 3.0.0. Is everyone ok with that?
Cheers,
Alex.
-----Original Message-----
From: mdt-ocl.dev-bounces@xxxxxxxxxxx [mailto:mdt-ocl.dev-bounces@xxxxxxxxxxx] On Behalf Of Ed Willink
Sent: Friday, July 17, 2009 8:43 PM
To: MDT OCL mailing list
Subject: Re: HA: [mdt-ocl.dev] Compatibility Support
Hi
Great, I think we are agreed. 1.4.x is an enhanced maintenance release for Helios. Since we will be maintaining 1.3.0, 1.3.1, 1.3.2 in parallel with 2.0.0, supporting 1.4.0 can't be that different.
Perhaps 1.4.0 gets no further maintenance release to avoid a 1.4.1,
2.0.1 and 2.1.0; not today's
problem anyway.
One minor problem; API tooling.
Because UML2 went from 2.x to 3.x for Galileo, the MDT-OCL UML plugin had to go from 1.x to 2.x, so 1.3.x and every subsequent release has a mismatch of MDT-OCL numbers; 2.0.0 will have a 3.0.0 for UML. Do we want to skip 2.0.0 and go straight to 3.0.0 (any of my earlier comments for 3.0.0 features should then be interpreted as 4.0.0)? This has an advantage in avoiding any confusion that MDT OCL 1.x is OCL 1.x and MDT-OCL 2.0.0 is OCL 2.x.
If EMF or UML2 or ... has a major API change in Helios, then we cannot go to 1.4.0 for a maintenance release while complying with API tooling policy. If this happens, I think we perform API testing in so far as possible ignoring only the major increment. i.e. in our workspace we temporarily name the 1.4.0 plugins as 2.0.0 check the API compliance, then restore the name to 1.4.0 and distribute with a major version API exclusion filter.
Regards
Ed Willink
Alexander Igdalov wrote:
> 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
>>
>
> --
>
> *Adolfo Sánchez-Barbudo Herrera*
> adolfosbh(at)opencanarias(dot)com
> <mailto:adolfosbh%28at%29opencanarias%28dot%29com>
> C/Elías Ramos González, 4, ofc. 304
> 38001 SANTA CRUZ DE TENERIFE
> Tel.: +34 922 240231 / +34 617 718268
>
> ----------------------------------------------------------------------
> --
>
> _______________________________________________
> 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
