[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[mdt-ocl.dev] Re: OCL sources tagged and branched
|
Ed,
I am indeed subscribed to mdt-ocl.dev. I didn't send this mail to it as
I simply hit "respond to all" :p.
Laurent
Ed Willink a écrit :
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.
