Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Should DSF UI packages be an API?

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)


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,
cdt-dev mailing list


Back to the top