[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