Hi John,
I agree with what you say. This is our chance to cleanup API and we have to do it now (and regularly in the future) to keep CDT maintainable.
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.
That said, we (CDT devs) have a responsibility to people who are active in the community to not make life unnecessarily hard for them. I think this is a perfect test case (as was TCF a couple of months ago). Someone depending on CDT came along, tried out the new release before it was released, and found their code didn't work. Working with them (GNU ARM now and TCF earlier) we determined that the cleanup had to mostly happen on their side to keep up to date with the APIs.
In the case of TCF, the review led mostly to removing some defunct dependencies. Then we were left with one awkward API change. The decision was to copy the new code from
http://eclip.se/456116#c10 from CDT 9 into TCF so that TCF could continue to work with CDT 8 and CDT 9 from a single source and binary distribution.
In the case of GNU ARM the issues were almost identical to TCF. In addition though there was another class that needed to be copied, but copying it is not straightforward
http://eclip.se/488909#c3 as it has lots of dependencies too. Therefore I think the best solution is to clean up the code as was done in Bug 488909, but maintain the original API too. That resurrection is covered by
http://eclip.se/494504.
I hope I have done enough to satisfy everyone that careful consideration has been undertaken on these changes and that there are no objections to
http://eclip.se/494504 for CDT 9.0.
Jonah
