Re: [mdt-ocl.dev] OCL versions

[Adolfo Sánchez-Barbudo Herrera <adolfosbh@xxxxxxxxxxxxxxxx>]

Hi Ed, Kenn

I knew why Christians changed the ocl.uml version number. The point is that the same discussion should have been arisen and resolved some months ago. If  "Christian made a reasonable decision not to inflict a major increment non-UML OCL users, so kept those at 1.x.", I guess that It could be a reasonable decision make the non-UML plugins evolve from 1.3.0 to 2.0.0..... I hope UML don't change their APIs again, because some innocent plugins would consequently have to increase their major version number as well. In anycase, I don't feel uncomfortable having all the MDT-OCL project in the 3.0.0 version, so let's do it !!!! ;)

Cheers !!!
Adolfo.

Kenn Hussey escribió:

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

    

--

Adolfo Sánchez-Barbudo Herrera adolfosbh(at)opencanarias(dot)com C/Elías Ramos González, 4, ofc. 304 38001 SANTA CRUZ DE TENERIFE Tel.: +34 922 240231 / +34 617 718268