[cdt-dev] RE: [cdt-debug-dev] List of Plan items

[Doug Schaefer <DSchaefer@xxxxxxx>]

Breaking API is never a good thing. Really the focus of the 4.0 release as far as APIs go is to identify the APIs that we want to freeze going forward. Some of the less mature APIs will likely undergo change so that we freeze them in at a higher quality level. The CDI is pretty mature in it’s current state so I don’t anticipate much change. But as Mikhail mentions, if the community approves API changes, they can happen.

 

I will be starting this week to put together guidelines like this for us to vote on and follow. If anyone has any input on the process that we should follow for API management, please let me know and I’ll try and integrate it.

 

Doug Schaefer
QNX Software Systems
Eclipse CDT Project Lead
http://cdtdoug.blogspot.com

 

---

From: cdt-debug-dev-bounces@xxxxxxxxxxx [mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail Khodjaiants
Sent: Wednesday, October 18, 2006 11:53 AM
To: CDT Debug developers list
Subject: RE: [cdt-debug-dev] List of Plan items

 

John,

 

I don't think anyone is planning to break compatibilty. All API changes and extensions should be discussed and approved by the community.

 

Mikhail 

---

From: cdt-debug-dev-bounces@xxxxxxxxxxx [mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
Sent: 18 October 2006 16:35
To: CDT Debug developers list; CDT Debug developers list; CDT Debug developers list
Subject: RE: [cdt-debug-dev] List of Plan items

I wanted to re-post this question, as I didn't get any feedback. A decision one way or another on this matter will have a significant impact in how we approach changes we make for CDT 4.0.

John

At 07:22 AM 10/17/2006, John Cortell wrote:

At 12:58 PM 10/16/2006, Alain Magloire wrote:

I do not see any difficulty except that it will break backward compatibility
but since this is targeting a major release, it should not be a problem.

Hm. I'd like to stop for a second and discuss this point. Is it true that we should be OK with breaking CDI compatibility in 4.0? We're working on various features (which we will contribute for 4.0) where we go out of the way to not break compatibility, by, e.g., introducing an ICDIThread2. If we're looking at breaking compatibility anyway, then there's no point in use going this messier route.

--

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.