|Re: [cdt-dev] Kepler: CDT 8.2 or 9.0?|
I guess it really depends on what the API change is. If it's a small number if Interface2's you end up creating then I'd prefer we do that and keep Kepler minor. If it's a major overhaul that will provide great benefit to ISV's in our ecosystem, then I'm OK with the major bump. I guess I'll need to look at it a bit more before I can decide.
(best non-answer ever ;p)
From: <Oberhuber>, Martin <Martin.Oberhuber@xxxxxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Friday, 22 June, 2012 1:20 PM
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] Kepler: CDT 8.2 or 9.0?
My 2 cents: If you silence API tooling, you should call it CDT 9.0 none the less.
This makes people at least aware.
On Behalf Of Sergey Prigogin
My vote is for ISomeInterface2 unless you can demonstrate with a high degree of certainty that the API change in spite of being formally incompatible is not going to break anybody.
On Fri, Jun 22, 2012 at 8:24 AM, Cortell John-RAT042 <RAT042@xxxxxxxxxxxxx> wrote:
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.