I realize folks are focused on Juno and few want to even think about Kepler at this point, so please excuse this interruption.
I’ve started merging in some changes James Blackburn shelved last year and they were coded assuming a CDT major version bump (i.e., they break API compatibility). I know, I know…we
finally release a CDT without breaking API and before it’s even out the door, someone is talking about ending the “streak”. More apologies.
The dilemma is that adjusting James’ solution to not break API is going to require the well-known ugliness of ISomeInterface2, and all the nasty underlying logic associated with
it. I’m prepared to do it (in fact, I’ve already started). However, if there is already a mounting need elsewhere to make Kepler CDT 9.0, then all my adjusting will be pointless. The API breakage associated with these changes are technical, not actual. I.e.,
API tooling flags it as breaking API, but it’s pretty doubtful it would actually break any clients.
I suppose an alternative is to use a filter to silence the errors—basically telling API tooling we’re OK with the technical API break. Has anyone done this before? Certainly, I would
consult the list with the details of these API changes to ensure everyone is on board with letting them slide as non-breaking.
This message is basically what I posted in bugzilla 331031 yesterday, but I’m since thinking the bugzilla update may fly under the radar for some.
John