[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
