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