[
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
|
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.
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.

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.
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.
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.
_______________________________________________
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