| Re: [cdt-dev] Should DSF UI packages be an API? |
|
Cool, sounds like we have a consensus :-) I will take care of marking
the packages as internal before the M6 build. I am also trying to
complete a refactoring of the label providers to get rid of the
deprecated IDMService.getModelData(), so I'm modifying many of the
related APIs already. Cheers, Pawel Leherbauer, Anton (Toni) wrote: I am also for 1). I don't think it is more effort on our side (provided we don't rename the packages). Toni-----Original Message----- From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Rohrbach, Randy Sent: Friday, March 06, 2009 5:59 PM To: CDT General developers list. Subject: RE: [cdt-dev] Should DSF UI packages be an API? I know Mark voted for 2 ( because it is easier ). I guess though from a purist point Of view we should do #1. This seems more by the book correct to me. Randy -----Original Message----- From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech Sent: Thursday, March 05, 2009 3:53 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 _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev |