Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] API change for 179393

I distinctly remember discussions where it was said that, at least with respect to the debugger, we needed to make an earnest effort to lock down the APIs and not keep breaking CDI clients with each release. Since that time, considerable pains have been taken to expand the CDI APIs in ways that maintain backward compatibility. To now hear an opinion that we shouldn't worry too much about API breaks is, honestly, a bit disheartening. I don't know if your opinion is intended to apply to CDT's APIs in general, or just specific ones. But we need some clear direction, because without it, one developer will bend over backwards to avoid breaking compatibility, only to have another come along and break it, effectively making pointless the extra effort the other took to avoid it.

If we can all agree that breaking compatibility is OK in a major release, then I have no problem with that. But we all have to be on the same page one way or another on this issue so that we can all develop with the same boundaries in mind. It makes a huge difference when you're looking at fixing a bug or adding a new feature whether or not you need to avoid changing existing interfaces.

John

At 11:17 PM 4/3/2007, Doug Schaefer wrote:
I have no problem with this. I'm not convinced we need an API freeze at this
stage of CDT's life. Maybe if we had more plug-ins building on top of us
that might be important. But I'm not sure everyone feels this way.

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


> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Chris Recoskie
> Sent: Tuesday, April 03, 2007 2:19 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: [cdt-dev] API change for 179393
>
>
> Folks,
>
> While I was on vacation Mike posted a patch to Bugzilla for the following
> bug:
>
> 179393:  factor IScanner.addDefinition(IMacro) into its own interface
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=179393
>
> This patch requires extracting part of the IScanner interface into another
> interface.  This allows other non-IScanner based parsers such as our C99
> parser to be able to pull macro definitions from the index.
>
> Since this requires some small API changes I would like to get consensus
> on
> applying this patch before I do so.  Are there any objections before I go
> ahead and do this?  No one has commented on the bug.
>
> ===========================
>
> Chris Recoskie
> Team Lead, IBM CDT Team
> IBM Toronto
> http://www.eclipse.org/cdt
>
> _______________________________________________
> 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



Back to the top