|Re: [cdt-dev] Kepler: CDT 8.2 or 9.0?|
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.
cdt-dev mailing list