Re: [cdt-dev] Scanner Discovery API and versioning of cdt.core

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

Hi,

 

The error I see is:

 

org.eclipse.cdt.codan.internal.ui.cxx/META-INF/MANIFEST.MF Version Numbering Problem

The major version should be incremented in version 2.0.0, since API breakage occurred since version 2.0.0  

 

What is weird is that if I push the version to 3.0.0, it does fix the error, but using the API Compatibility

setting I mentionned below, still does not show what is the API change that triggers the error...

If it helps, I've been seeing this error for some months now; I even think it's been there almost since

the start of the new CDT cycle.

---

From: laskava@xxxxxxxxx [mailto:laskava@xxxxxxxxx] On Behalf Of Alena Laskavaia
Sent: Thursday, December 29, 2011 8:06 PM
To: Marc Khouzam
Subject: Re: [cdt-dev] Scanner Discovery API and versioning of cdt.core

What is the error?

On Fri, Dec 23, 2011 at 3:53 PM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:

We should strive to avoid API-breaking changes when it does not add too much complexity.

And we should again document the API breaking changes.

 

For properly documenting the changes, there is a trick I just found:

 

After API freeze, each committer responsible for a component (or someone else)

should turn on the option to

    "Report API breakage even if authorized by major vesion increment"

 

Each of these reported errors should be documented.

 

Maybe we can even export all compiler errors once that option is

enabled and that could serve as our documentation.  If that is possible,

a single person could do it right after CDT Juno is released.  Easy.

 

Wouldn't that be a nice thing for our adopters?

 

As expected, there is currently only one such error in CDT master, in codan.

 

 

 

---

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schaefer, Doug

Sent: Friday, December 23, 2011 3:29 PM

To: CDT General developers list.
Subject: Re: [cdt-dev] Scanner Discovery API and versioning of cdt.core

Well, it looks like we have a couple of major updates coming to the core. The real question, though, is it going to make downstream adopters lives painful?

 

Doug.

 

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

 

I like the idea of naming CDT after the train.

 

No major udpate of version in Debug, although if someone else needs a 9.0, it would make my life easier ;-)

 

 

---

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

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.

 

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.

 

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