Re: [mdt-ocl.dev] OCL versions

[Kenn Hussey <kenn.hussey@xxxxxxxxx>]

Note that the rules for individual plug-in versions are clear, and I
agree that a major version change in a public dependency demands a
major version increment. We have a convention that the feature version
is the same as the highest plug-in version within it, so that pretty
much determines what the feature versions will be and, hence the
version of the component as a whole (although I wish components were
versioned based on release name rather than a number)...

Cheers,

Kenn


On 7/30/09, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
> Hi Adolfo
>
>> About MDT-OCL 3.0.0. Sorry, I read about it, but I haven't said
>> anything. I think we must find an answer to the following questions:
>>
>> Why MDT-OCL 1.3.0 has a plugin versioned as 2.0.0 (UML one). Is this
>> intentional, or just a Christian's mistake ?. Should have all the
>> plugins been versioned as 2.0.0. I guess that if we have an answer to
>> this question, we must get the clue of which version number must be
>> given to the MDT-OCL project in the Helios release:
> API tooling requires that a major increment by a dependency is
> propagated, so when UML2 had a major increment org.eclipse.ocl.uml had
> to too.
>
> Christian made a reasonable decision not to inflict a major increment on
> non-UML OCL users, so kept those at 1.x.
>>
>> If it's intentional/valid/correct: MDT-OCL 2.0.0 would have
>> org.eclipse.ocl and org.eclipse.ocl.ecore 2.0.0 plugins and
>> org.eclipse.ocl.uml 3.0.0 plugin.
> That's locally sensible but globally confusing.
>> If it's just a mistake: MDT-OCL 3.0.0 would have all their plugins in
>> the 3.0.0 version.
> I don't understand this. Mistake or not, that's where we are. We cannot
> re-release all UML OCL parts of Ganymede.
>>
>> The last possibility is: In spite of being intentional/valid/correct,
>> we may want to have all the plugins in the 3.0.0 version. From my
>> point of view it's a little bit strange stepping from MDT-OCL 1.3.0 to
>> MDT-OCL 3.0.0. In any case, I think that we must be lighted by Kenn or
>> another PMC. I don't honestly know if there is any policy/guideline
>> relating to this issue.
> That's what I suggested and Alex +1'd. It's the least bad solution. Kenn
> queried it and, by lack of further participation in the discussion,
> accepts the explanation.
>
>     Regards
>
>        Ed Willink
>
> _______________________________________________
> mdt-ocl.dev mailing list
> mdt-ocl.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
>

-- 
Sent from my mobile device