| 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 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 : --
|
