Hi Ed
Unfortunately evolution of the UML model changes a constraint and so
changes the validate functions visible to client Validators. The
UML2 4.0 change so far has one such change; there will probably be
many more for Indigo. This makes it very difficult for MDT/OCL to be
compatible with both UML2 3.x and 4.0 and equally difficult for UML2
4.0 to offer a clean UML 2.4 model while maintaining API
compatibility with 3.x.
http://wiki.eclipse.org/Version_Numbering#How_to_specify_versions_when_plug-ins_re-export_other_plug-ins
directs that all plugins exporting a major increment must also have
a major increment, and
http://wiki.eclipse.org/Version_Numbering#How_to_version_packages
directs that all features must also have a major increment.
Somewhere there is also a direction to keep major versions coherent,
so I see no alternative to a major increment for MDT/OCL for Juno.
To minimize M2 impact, we can probably just change our UML2
dependencies to [4.0.0,5.0.0) although that may leave downstream UML
clients in trouble, but no more than they're already in anyway. This
requires that we disable the API checking until we make a major
increment.
Is it best to have all this pain now for M2 or defer some more pain
till M3?
Regards
Ed Willink
On 22/09/2011 11:31, Ed Merks wrote:
David,
I'm not sure why so many clients would strictly upper bound their
EMF dependencies based on minor version increments. I know UML2
does this because they extend EMFs GenModel and hence its
implementation classes, but I don't expect a significant number of
clients to be so intimately dependent on EMF's minor versions. Of
course there could be quite a few things downstream from UML2 that
are affected...
Ed,
Clients (bundles) interested in UML2's version range can/should
have direct dependencies on UML2 itself and those dependencies can
reflect the range restrictions they feel are appropriate. They
don't need that information to trickle through your versions. Of
course if you make API changes in response to those of UML2, then
you'll want to make version changes to reflect that level of
change in your latest version.
Cheers,
Ed
On 22/09/2011 2:26 AM, Ed Willink wrote:
Hi David
Thanks for the early prompt. MDT/OCL at +1 will try to
contribute very soon.
But, just checking our dependencies for a MDT/UML2 M2, I notice
that I must have missed an announcement of a UML2 major version
change, so as I understand it, MDT/OCL and all downstream
projects must have a major version change too.
At present only an I-build exists for MDT/UML2 4.0 so that's
what we must use for now. An esartly M2 would help Kenn.
Regards
Ed Willink
On 22/09/2011 03:54, David M Williams wrote:
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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
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
|