[mdt-ocl.dev] RE: OCL sources tagged and branched

["Ed Willink" <ed@xxxxxxxxxxxxx>]

Hi All

Laurent: Are you subscribed to MDT-OCL dev? (If so you get two
copies of this message).

We really must use MDT-OCL dev for development discussions.

Hopefully every non-trivial change will go via a bugzilla patch
and/or a CVS branch so even HEAD changes should be approved by a
second committer.

1.3.1 etc will not support OCL 2.1, so we may diverge quite rapidly.
I foresee some rather significant type policy clean up to ensure
that OclAny is/isn't a supertype of a Collection as appropriate.
This is going to require some quite diligent JUnit testing.

I'm ok doing parsing. It would be good if someone became sufficiently
conversant with the OCL type appendices to ensure that some of the
difficult type issues e.g. https://bugs.eclipse.org/bugs/show_bug.cgi?id=184329
are sensibly addressed.

The roadmap is hinted at by https://bugs.eclipse.org/bugs/show_bug.cgi?id=237438
and associated child threads.

It would be good to summarise the ongoing conclusions into a Wiki page.

	Ed



> -----Original Message-----
> From: Laurent Goubet [mailto:laurent.goubet@xxxxxxx] 
> Sent: 25 June 2009 08:05
> To: Alexander Igdalov
> Cc: 'Adolfo Sánchez-Barbudo Herrera'; ed@xxxxxxxxxxxxx
> Subject: Re: OCL sources tagged and branched
> 
> 
> Hi all,
> 
> Whether it's worth commiting or not, I believe the maintenance branch 
> shouldn't see any commit except for bug fixes : I believe that is the 
> point of a "maintenance" branch :). On the other hand, as the next 
> release of OCL will be 2.0 (and it is most likely that this version 
> increase will see API breaks and the loss of backward 
> compatibility), I 
> think most clients relying on OCL will keep using 1.3 (or subsequent 
> "bug fix" releases of that stream) for a while. Maybe they'll 
> switch for 
> 2.1, maybe for later releases when they'll realise the 2.x 
> stream truly 
> provides notable enhancements ... but I truly doubt they'll 
> switch for 
> 2.0 right off the bat.
> 
> In this context I would also push for the team (at least one commiter 
> other than the coder) to review all patches aimed at the maintenance 
> stream; at least to do our best to prevent regressions and accidental 
> API break/leak.
> 
> On a whole different subject, I know I haven't been able to 
> take part in 
> OCL for now and have remained silent on most issues (often 
> because all 
> had already been said :p). As Galileo is now out, my work 
> load on EMF - 
> EMF Compare and M2T - Acceleo should subside with the rush. 
> Is there a 
> roadmap or planning available for OCL for us to know where to 
> start for 
> the upcoming release? On this issue, you might be interested 
> in knowing 
> that I am far from familiar with grammars and will probably 
> have trouble 
> in working on points related to it ... though I think Ed can 
> tackle just 
> about anything coming at us on this point :).
> 
> Laurent Goubet
> Obeo
> 
> Alexander Igdalov a écrit :
> > Hi Team,
> >
> > I have tagged OCL sources by 'R1_3'. I have also created a 
> new branch for Galileo maintenance - 'R1_3_maintenance'.
> > We can now start committing to HEAD which is the location 
> of the source code for Helios.
> > I don't think it's worth committing anything to the 
> maintenance branch except for possible critical bugs. If 
> these occur I suggest that the corresponding patches 
> submitted by one of us are to be reviewed by the rest of the team.
> >
> > Cheers,
> > - Alex.
> >   
> 
>