Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] CDT 6.0 and API
Mikhail,
the definition of API is easy, it's the content of all packages that are exported as public package in
the manifest.mf file. The API tooling will use exactly this information for performing checks on the API.
If packages are unintentionally exported as public, we need to remove the public export, which is a
breaking API change.
 
I did not start and argument about whether API changes are necessary or not. I want to discuss, how
we can carry out API changes in an organized manner. What's your opinion on that?
 
Markus.

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail Khodjaiants
Sent: Monday, October 20, 2008 12:12 PM
To: CDT General developers list.
Subject: RE: [cdt-dev] CDT 6.0 and API
Importance: Low

Hi Markus,
 
On the debugger side we have been following these rules since the beginning. And I have always opposed to what Doug calls "a cowboy approach".
But since I have started to look at the other parts of CDT (core and build) I have had problems to understand what is meant to be API there and what is not. Some developments seem to be started but then abandoned. Some old interfaces are marked as deprecated without mentioning the replacements for it, others are left without deprecation. In some cases I couldn't understand why a class or an interface was implemented as public or internal. It seems that people who work closely with core (and possibly build) have an understanding of what is public but it is not obvious for outsiders like myself.
My opinion is: a serious cleanup is required which may cause an API breakage. Not sure if we have resources for it though :(
 
Regards, 
Mikhail

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schorn, Markus
Sent: Monday, October 20, 2008 10:17 AM
To: CDT General developers list.
Subject: [cdt-dev] CDT 6.0 and API

Hi committers,
For two reasons, I am missing a discussion about the planned changes to the API.
* Even if we deliver CDT 6.0 and thus do break API, we should be nice to our clients and keep
  the changes to the API minimal. Therefore an API change needs some justification. In many cases
  it is possible to provide a fix that only extends, but does not break API.
* A single committer is usually not aware of all the use-cases for an API and therefore an API change
  should be discussed before it is carried out.
 
Basically I would like to know about the planned API changes, but I also think that we should take this
further by making it mandatory to discuss a breaking change to AP on bugzilla, first. It is also a good
habit to inform committers about non-breaking extensions to API.
 
Please share your opinion,
Markus.
 

--

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

Back to the top