Community
Participate
Working Groups
(In case you missed the cross-project-dev announcement; IPlatformRunnable is to vanish. Bug 457134) It looks like the deprecation was accommodated 10 years ago, so removal is easy. However the org.eclipse.emf.codegen extension points still use the deprecated PlatformRunnable; probably should have been moved over 10 years ago.
Apparently this will actually be deleted in two years: https://bugs.eclipse.org/bugs/show_bug.cgi?id=457134#c19 So I'll defer action for that long as well.
The cross-project-dev message confused me. marked-for-deletion seems to be a substantial new phase between deprecated and gone. Suppose the deletion actually occurs in Photon+1, EMF 2.15 then has to lose the last vestige of a reference. EMF 2.14 with a useless reference may fail with a CNFE on Photon+1. In principle this is not EMF's problem since the platform has broken API without a major version change. However in the real world, we now allow suitably announced API breakage without a major version change. Surely it would be better to remove the useless reference now, so that there is an EMF/platform compatible version range overlap. Any application that actually needs the useless reference has not been maintained for 10 years and will probably break when the platform changes anyway. Better to provide a compatibility range for current users than a minor extension for totally obsolete use. I've not studied the code but if you're after extreme compatibility, it might be possible for EMF to provide a local 'clone' to avoid the broken reference giving a CNFE.
(In reply to Ed Willink from comment #2) > The cross-project-dev message confused me. marked-for-deletion seems to be a > substantial new phase between deprecated and gone. > I think it was previously not properly marked so now it is marked... > Suppose the deletion actually occurs in Photon+1, EMF 2.15 then has to lose > the last vestige of a reference. EMF 2.14 with a useless reference may fail > with a CNFE on Photon+1. Well we're moving to a new 4 times a year release schedule without branded names, but in principle there will be 8 releases over the next two years before the class is removed... > In principle this is not EMF's problem since the > platform has broken API without a major version change. However in the real > world, we now allow suitably announced API breakage without a major version > change. > It seems to me the platform team is being a little overly fussy by deleting trivial classes as if that will make maintenance so much better/easier, but it's not my choice to make for them. I'm just not happy that I have to make changes that are potentially breaking for my own clients. In any case, all EMF's implementations of IPlatformRunnable already implement IApplication so I doubt any clients will be affected by my removing the uses of extends org.eclipse.core.runtime.IPlatformRunnable. > Surely it would be better to remove the useless reference now, so that there > is an EMF/platform compatible version range overlap. Any application that > actually needs the useless reference has not been maintained for 10 years > and will probably break when the platform changes anyway. Better to provide > a compatibility range for current users than a minor extension for totally > obsolete use. > I'm not sure what concretely you're suggesting by "provide a compatibility range". I'm not sure how it's better to break clients sooner rather than later either. > I've not studied the code but if you're after extreme compatibility, it > might be possible for EMF to provide a local 'clone' to avoid the broken > reference giving a CNFE. I doubt any client is using any of the implementation classes via the IPlatformRunnable API so removing it is highly unlikely to harm anyone. I just don't feel compelled to take action two years ahead of when it is needed...
compatibility range. Currently I think that it is possible to install emf 2.10 TO 2.14 on platform 4.4 to 4.8, which is useful because some modeling projects are tightly couple allowing a Neon too suite on a more recent/older platform. If I am correct in thinking that the breakage could lead to a CNFE at EMF 2.15/platform 4.9, then we would not allow EMF 2.14 on platform 4.9. Deleting the useless reference no will allow 2.14 to be used on platform 4.4 to 4.8 and 4.9 to ... So yes, breaking clients earlier is not good, but there are surely very very few 10 years on. Indeed they must be pre-e4. Almost certainly only interested in unaffected standalone usage. In contrast users mixing and matching recent platform/EMF versions are a more substantial community so doing what does 'no harm' now rather than in perhaps two years does some good.
(In reply to Ed Willink from comment #4) > compatibility range. > > Currently I think that it is possible to install emf 2.10 TO 2.14 on > platform 4.4 to 4.8, which is useful because some modeling projects are > tightly couple allowing a Neon too suite on a more recent/older platform. > It's boarder than that. Helios through Photon all work and are tested by https://ci.eclipse.org/emf/job/all-target-platforms/ > If I am correct in thinking that the breakage could lead to a CNFE at EMF > 2.15/platform 4.9, then we would not allow EMF 2.14 on platform 4.9. Yes, or more likely 4.10 and with the new release train schedule, 4.16. > Deleting the useless reference no will allow 2.14 to be used on platform 4.4 > to 4.8 and 4.9 to ... > Yes, but life is a tradeoff and people installing the latest platform will of course have to go very far out of their way to install an old version of EMF because of course the newer version of EMF will be available in the train and that's what's likely to be installed. > So yes, breaking clients earlier is not good, but there are surely very very > few 10 years on. Indeed they must be pre-e4. Almost certainly only > interested in unaffected standalone usage. > Yes, the change is unlikely to break anyone. > In contrast users mixing and matching recent platform/EMF versions are a > more substantial community so doing what does 'no harm' now rather than in > perhaps two years does some good. Perhaps I'll reconsider; it's just easier to argue that I broke something because I had to than that I broke something in anticipation of having to break something two years from now. A number of uses are in deprecated classes, so I'd like to remove those too, but I've never removed anything ever, so I'm reluctant...
I highly doubt this removal will affect anyone: http://git.eclipse.org/c/emf/org.eclipse.emf.git/commit/?id=91b343d69dcd0c3520daf492d65d1fdd93742619
The changes are available in the 2.16 release: http://download.eclipse.org/modeling/emf/emf/builds/release/2.16
