| RE: [cdt-dev] Should DSF UI packages be an API? |
Hi, from an DSF user, I think the impact is about the same, basically, their code will need to adapt when this happens. So, lets make it easier on us. I vote for 2) Marc ________________________________ From: cdt-dev-bounces@xxxxxxxxxxx on behalf of Pawel Piech Sent: Thu 3/5/2009 3:52 PM To: CDT General developers list. Subject: [cdt-dev] Should DSF UI packages be an API? DSF integration with Debugger views relies on the Flexible Hierarchy provisional API in Platform Debug. This DSF component is designed to be an API itself, which allows debugger integrations to use it an extend it. However, depending on a provisional API in platform means that technically this part of DSF cannot be a final API. The flexible hierarchy API has actually evolved without breaking changes in Platform 3.4 and 3.5, but we do hope to make it a public API eventually, and because of that DSF UI will break backward compatibility at that point. I think we have two choices: 1) Mark the DSF UI APIs as provisional as well. I don't think we'd want to rename the packages, even though that is the convention, but we would at least need to mark them as internal in the plugin manifest file. 2) Leave it as public API, ignore the warnings, and commit to increasing the major version number of DSF when flexible hierarchy APIs have breaking changes in them. Thanks in advance for your input, -Pawel _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev
<<winmail.dat>>