Hi Adolfo,
Taking into account that MDT-OCL 2.0.0 will mainly tackle the OCL 2.1 specification, the MDT-OCL 1.3.x maintenance branch should just enclose implementation bugs which relate to OCL 2.0 specification. From my point of view we must focus MDT-OCL 2.0.0 >which would include any enhancement request. I agree that some clients would prefer to stay in the 1.3.x version due to compatilibily issues. However, MDT-OCL 2.0.0 will break APIS due to the new specification, so the clients may be encouraged to adopt >MDT-OCL 2.0.0 to be compliant to the specification. I would highly recommend to reduce the efforts invested on the maintenance branch.
The maintenance branch for OCL 1.3 is aimed to build maintenance releases for Galileo. Since then it will not be a part of Helios, our next release, and subsequent releases. Therefore, in case we want to support both OCL 2.0 and OCL 2.1 (and we do) we should support their implementations in HEAD. This is why legacy OCL (org.eclipse.emf.ocl*) is still in CVS HEAD. After we analyse the delta between OCL 2.0 and OCL 2.1 we will need to figure out the way to support their co-existence. Perhaps we will have to add new plugins for OCL 2.1, perhaps not. I would defer this decision until we have obtained the deviation list.
Again, since 1.3 branch is a maintenance stream IMO only real stoppers should committed to it. If these occur (which I hope won't happen) we will have to review the patches very carefully. Ed, I do not think the maintenance branch should contain improvements like https://bugs.eclipse.org/bugs/show_bug.cgi?id=276267.
Regarding the bugs considered to be worth doing (or at least deserve some thinking) in Helios, please set their target milestone to 2.0.0 as you have already started to. I think discussions on these bugs are better to have in bugzilla.
I think that I'll start to write in the OCL wiki a table/record relating the significant changes we will have to adopt from the OCL 2.1 release.
Great, thanks! AFAIU, the new 2.1 spec is to be approved today, right?
Cheers,
- Alex.
________________________________________
От: mdt-ocl.dev-bounces@xxxxxxxxxxx [mdt-ocl.dev-bounces@xxxxxxxxxxx] от имени Adolfo Sánchez-Barbudo Herrera [adolfosbh@xxxxxxxxxxxxxxxx]
Отправлено: 25 июня 2009 г. 22:31
Кому: MDT OCL mailing list
Тема: Re: [mdt-ocl.dev] RE: OCL sources tagged and branched
Hi All,
I agree that it would be good if at least one committer gives his OK before comitting changes to HEAD (2.0.0) or BRANCH (1.3.1). On the other hand I think that we shouldn't commmit any change without a previous bugzilla record. So the usual flow of work could be the following one:
- Raise a bugzilla bug/enhancement.
- Attach a patch to it and request for reviewing
- Waiting for another comitter OK.
- Commit
Taking into account that MDT-OCL 2.0.0 will mainly tackle the OCL 2.1 specification, the MDT-OCL 1.3.x maintenance branch should just enclose implementation bugs which relate to OCL 2.0 specification. From my point of view we must focus MDT-OCL 2.0.0 which would include any enhancement request. I agree that some clients would prefer to stay in the 1.3.x version due to compatilibily issues. However, MDT-OCL 2.0.0 will break APIS due to the new specification, so the clients may be encouraged to adopt MDT-OCL 2.0.0 to be compliant to the specification. I would highly recommend to reduce the efforts invested on the maintenance branch.
We must start planning the work for Helios release. I think that I'll start to write in the OCL wiki a table/record relating the significant changes we will have to adopt from the OCL 2.1 release.
Cheers,
Adolfo.
Ed Willink escribió:
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<mailto: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.
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx<mailto:mdt-ocl.dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
--
[cid:part1.01020704.07060904@opencanarias.com]
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
