| [mdt-ocl.dev] Fwd: [cross-project-issues-dev] Juno M2 aggregation -- will it be the worst milestone ever? |
|
Hi Adolfo We could be part of a problem here. Let's plan to contribute an M2 this evening against Platform/EMF M2, UML 4.0Ixxxxxx, etc Ixxxx and expect to respin M2a, M2b etc as other projects catch up. If necessary we contribute without examples initially. Better to have OCL without examples than no OCL at all. I'm just downloading UML2 now. We will probably need to remove the 4.0 upper bound for M2, but retain the lowerbound at 3.0 temporarily. If UML2 has a major version then we should too!!! and if everyone who uses UML2 has got to adjust once then it would help if our major version change was for M2. Perhaps we contribute 3.1M2 today and 4.0M2 as soon as UML2 4.0M2 is out. Alex: A major change gives us more discretion about what we do for Juno. We still want practical compatibility, but perhaps not totally paranoid compatibility. Regards Ed Willink -------- Original Message --------
Well, no, probably not ... but, it will take a lot of attention to get it done on time. First greatest thanks to Kenn Hussey for making (or fixing) an "early" contribution repository [1] for EMF core (or, "base", I think they are now calling the platform-shared parts. This allows Eclipse 4.2 M2 and EMF M2 to both be installed from repository sites. (For full issues, and longer term improvements, you can follow bug 356644). Now the problem is that the new version of EMF (and maybe Eclipse M2?), apparently, breaks numerous other contributions, apparently due to increased minor version numbers (combined with narrow ranges?). To aggregate, at the moment, I would have to disable about 20 of the b3aggrcon files in org.eclipse.juno.build. I can (and may) do some disabling, .... but, thought it would be a good time to review the process and timing of making contributions to an aggregation build: you do not have to wait until your +n day to make a contribution. You can make a "warm-up" contribution at any time ... especially if it is needed to allow the aggregation to succeed. In other words, your +n day is the last possible day to make a contribution ... not the first day you may make one. Many of the current problems are "ripple effects" from a few low level, commonly used bundles or features (in modeling projects, it appears) so, maybe with only a few fixes we'll be on the right path again, but, I ask that teams try to respond as quickly as possible to fix any "aggregation errors" they get notified about ... please do not think you can wait until your final contribution next week ... and even if you have not been notified yet, if you use EMF, please "peek ahead" with the M2 versions of Eclipse and EMF base and prepare an early version, even if you re-contribute your final version during the (final) window next week. After all, if we had to do a true "iteration" waiting for each of 20 project to fix their builds sequentially before the next one fixes theirs, then we will not finish in time. Thanks, for your attention, let us know if questions or issues. [1] http://download.eclipse.org/modeling/emf/emf/updates/2.8milestones [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=356644 |
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1410 / Virus Database: 1520/3911 - Release Date: 09/21/11