|Re: [cdt-dev] missing org.eclipse.cdt.debug.mi.core in Neon?|
This one is on me.
I removed APIs that were not deprecated. I new this was a risk but I made
a judgement call that in this particular case, it was better for extenders in the long run.
I asked for opinions here: https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg30262.html
and here: https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg30265.html
To be clear, I feel this approach should be the _exception_ and not the rule. But exceptions
are sometimes valuable. All the more so, when opportunities to improve API come every 5 years
or so. To be fully transparent, there probably still are one or two removals of non-deprecated
APIs as part of CDT 9.0.
Doug had the foresight to move up API-breaking freeze to M6, which gave extenders ample
time to try to compile with CDT 9.0 and notice anything particularly disturbing to them; giving
us time to react and fix things. But I understand that with contributors'/extenders' time
being limited, just as our time is limited, it is often difficult to test as early as we would wish.
I'm glad this particular issue was reported in time for us to react.
And I'm glad Jonah jumped on this so quickly to resolve it.
The comforting thought is that the next API-breaking version of CDT is probably not
before 5 years in the future :)
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of John Cortell [john.cortell@xxxxxxx]
Sent: May 25, 2016 11:18 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] missing org.eclipse.cdt.debug.mi.core in Neon?
> As far as deprecating API, CDT does not have a deprecation policy, certainly
> nothing like the quite heavyweight one the platform does. The reality is if
> we did have such a policy, I don't think this kind of code clean-up would
> ever happen. The removal of CDI and the code cleanup was announced
> well in advance on the mailing list.
Sorry to extend this thread even further. IMO, the best mechanism for giving a heads-up on API cleanup is through annotations. That is far more effective and reliable than mailing lists, EclipseCON presentations and BOFs, wikis, etc. You are advertising your intentions directly to every developer that is integrating CDT into a product, injecting the notification directly into his development workflow. If the developer has turned off such warnings/errors, or fails to act on the markers…oh, well. Not your fault; it’s his.
This isn’t about a heavyweight process. It’s mostly about being patient and taking due diligence. If today you decide you’d like to remove a public type, method or field, annotate it “@Deprecated // in Neon”. In every future major release cycle, you would grep the codebase for these annotations and see which ones are suitable for executing on based on when they were deprecated (recorded in the comment) and whether it has crossed the acceptable threshold (2 or 3 years, e.g.).
If it feels heavyweight, OK. But I guess that’s the price you pay when you’ve created SW that exposes API that hundreds of developers have latched on to. The only acceptable alternative, IMO, is to never clean up API, which is not a good solution in my book. Anyway, I’m butting in here only because I think it would be good if we do more than just avert this particular break of GNU ARM Eclipse. Hopefully there will be some process/behavioral change that will make this situation less likely to happen again.
cdt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
Back to the top