Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Scanner Discovery API and versioning of cdt.core


On Fri, Dec 23, 2011 at 11:48 AM, Schaefer, Doug <Doug.Schaefer@xxxxxxxxxxxxx> wrote:

Did any plugin get a major version bump yet? If there are no API changes, I’d prefer to leave it at 8.1. It would be nice to send a message we are finally taking care of our APIs so that extenders can do so without worrying of breakage from release to release.


There is an outstanding API breakage in org.eclipse.cdt.codan.internal.ui.cxx (The major version should be incremented in version 2.0.0, since API breakage occurred since version 2.0.0) plus the API changes in the Scanner Discovery described by Andrew.
 

 

I also prefer to name the CDT releases by their train. The next one is CDT Juno. Which I guess is why I haven’t fussed about the number.

 

Doug.


-sergey 

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sergey Prigogin
Sent: Friday, December 23, 2011 2:09 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Scanner Discovery API and versioning of cdt.core

 

 

On Fri, Dec 23, 2011 at 6:21 AM, Andrew Gvozdev <angvoz.dev@xxxxxxxxx> wrote:

There are 2 interfaces that were changed in cdt.core and that cause breaking API changes as reported by API tooling. Both interfaces are presumable of internal kind but not marked currently as such:

- org.eclipse.cdt.core.settings.model.ICDescriptionDelta

- org.eclipse.cdt.core.settings.model.ICSettingEntry

 

I marked both as @noextend/@noimplement which is breaking by itself.

 

ICDescriptionDelta is to create a delta for event notification which is done internally in the model. I do not believe users should be allowed to implement it.

I am less convinced about ICSettingEntry but we had some discussion about it earlier and James was of the opinion that it should be marked as internal. I would concur unless somebody provide a good reason for extending.

 

So, on sd90 branch I marked them as @noextend/@noimplement and added to API filters which allowes not to increase the major version of cdt.core. Would it be appropriate to do in this case?

 

This also brings up a question what is the next version of CDT itself, is it CDT 9.0 or CDT 8.1 ?

 

+1 for 9.0. The changes (not the API, but the scanner discovery in general) are large enough to warrant a new major version.

 

Thanks,

Andrew

 

-sergey 


_______________________________________________
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