The Cost Of Breaking Changes

0 comments suggest edit

broken-glass One interesting response to my series on versioning of interfaces and abstract base classes is the one in which someone suggested that we should go ahead and break their code from version to version. They’re fine in requiring a recompile when upgrading.

In terms of recompile, it’s not necessarily recompiling yourcode that is the worry. It’s the third party libraries you’re using that poses the problem. Buying a proper third-party library that meets a need that your company can be a huge cost-saving measure in the long run, especially for libraries that perform non-trivial calculations/tasks/etc… that are important to your application. Not being able to use them in the event of an upgrade could be problematic.

Let’s walk through a scenario. You’re using a third-party language translation class library which has a class that implements an interface in the framework. In the next update of the framework, a new property is added to the interface. Along with that property, some new classes are added to the Framework that would give your application a competitive edge if it could use those classes.

So you try and recompile your app, fix any breaks in your app, and everything seems fine. But when you test your app, it breaks because the third party library is not implementing the new interface. The third party library is broken by this change.

Now you’re in a bind. You could try to write your own language translation library, but that’s a huge and difficult task and your company is not in the business of writing language translators. You could simply wait for the third party to update their library, but in the meanwhile, your competitors are passing you by.

So in this case, the customer has no choice but to wait. It is my hunch that this is the sort of bind we’d like to limit as much as possible. This is not to say we never break, as we certainly do. But we generally limit breaks to the cases in which there is a security issue.

Again, as I’ve said before, the constraints in building a framework, any framework, are not the same constraints of building an app. Especially when the framework has a large number of users. When Microsoft ships an interface, it has to expect that there will be many many customers out there implementing that interface.

This is why there tends to be an emphasis on Abstract Base Classes as I mentioned before within the .NET Framework. Fortunately, when the ABC keeps most, if not all, methods abstract or virtual, then testability is not affected. It’s quite trivial to mock or fake an abstract base class written in such a manner as you would an interface.

Personally, I tend to like interfaces in my own code. I like the way I can quickly describe another concern via an interface and then mock out the interface so I can focus on the code I am currently concerned about. A common example is persistence. Sometimes I want to write code that does something with some data, but I don’t want to have to think about how the data is retrieved or persisted. So I will simply write up an interface that describes what the interaction with the persistence layer will look like and then mock that interface. This allows me to focus on the real implementation of persistence later so I can focus on the code that does stuff with that data now.

Of course I have the luxury of breaking my interfaces whenever I want, as my customers tend to be few and forgiving. ;)

Technorati Tags: Framework,Design,Software,Interfaces

Found a typo or error? Suggest an edit! If accepted, your contribution is listed automatically here.



43 responses

  1. Avatar for Mike
    Mike March 3rd, 2008

    Is this post to prepare us for breaking changes in the new ASP.NET MVC release?

  2. Avatar for hgs
    hgs March 3rd, 2008

    "When Microsoft ships an interface, it has to expect that there will be many many customers out there [...]."
    A case in point: Under XP I have made my scrollbars about 1.5cm wide. I did that through the Accessibility Wizard. I can't do it in Vista. The "Easy Access" centre doesn't provide that. It's apparently hidden somewhere, but no books on vista that I have seen tell me where it is, and the available help (it's not connected to the net) has nothing. It took me long enough to find the "Easy Access" centre, given that the term used by disabled people for this sort of thing is "accessibility". So although the search facility on the Start menu is a big improvement, it didn't help here.

  3. Avatar for Eamon Nerbonne
    Eamon Nerbonne March 3rd, 2008

    Of course, using extension methods can provide a work-around in many cases.
    I find that the lack of multiple inheritance makes ABC's terribly annoying to work with. Helper classes with syntactic aids such as extension methods can help maintain binary compatibility in those cases where the new interface is merely an extension of the old.
    If you're only providing new utility functions which don't affect the core capabilities, why not use an interface [i]and[/i] an ABC/utility wrapper? If you are introducing new, important changes which can't trivially be introduced, then the problem lies not with the versioning differences between interfaces and abstract base classes, but in the new functionality, and ABC's won't help.
    In my experience, dealing with ABC's is much more frustrating than dealing with interfaces for three reasons: Firstly, precisely because they indeed can include hidden functionality designs using them are less transparent and more difficult to understand and debug, and worse yet, indeed they can add this functionality in non-obvious places after the fact. Secondly, using an ABC often precludes using an appropriate base class since you're forced to use the one provided. Also, you can use only one ABC, which means that orthogonal concepts can't be combined despite there being no technical reason for that limitation. A combined interface+ABC approach would at least allow for the ugly but functional wrapper-object approach which simply forwards all methods of interface A to the appropriate instance and all methods of interface B to the appropriate interface. Thirdly, and not irrelevantly, ABC's often lead to badly designed and bloated API's precisely because it's so easy to increase their size. This may not be a causal relationship, but it's uncanny how much cleaner the core .NET frameworks interfaces are than the core .NET frameworks classes.
    Let's also not that it is possible to use generics trick to make interfaces which can be extended with new functionality without breaking changes, but really, all this shows is that the C# and the .NET framework really fail at providing mix-in like functionality. This isn't so much a difference between dynamic and static languages (although clearly it's a more obvious feature in dynamic languages), as a slightly more complex feature. A class with a mix-in isn't really much more than a class with a generic parameter T, and one read-only field of that type T which is initialized appropriately.
    My vote is against ABC's, in all cases excepting only those where the object has an inherent coupling to the platform (such as where alternate implementations might pose a security risk, like the array or list types do).

  4. Avatar for Karthik Hariharan
    Karthik Hariharan March 3rd, 2008

    The issue you brought up with third party libraries breaking is valid, but ultimately I think such issues need to be addressed by the third party vendor and they should stay on top of any framework changes to make sure their customers aren't stuck in a bind.
    If testability is the number one reason for MVC, then I think it is reasonable to expect vendors to make their libraries more testable and hence expose any breaking changes sooner so they can get the fixes out to their customers more quickly.
    Thats the whole point of TDD, right? Quickly pinpoint failures and fix them with the confidence that you have test coverage to back you up :)

  5. Avatar for Justin
    Justin March 3rd, 2008

    LOL mike, I hope not. All this focus on breaking changes is starting to make me wonder. :D

  6. Avatar for Francois Ward
    Francois Ward March 3rd, 2008

    I still think the backward compatibility thing isn't as big as deal as they make it seem.
    Fact is, when I get a 3rd party library, it either:
    A) Depends only and purely on the base framework. That is, 1.1, 2.0, 3.5, etc. Virtually all third party libs need to recompile for those, for a reason or another.
    B) They depend on other stuff (like in the future the MVC framework), but also on 3rd party stuff themselves, who will not care as much about backward compatibility. So they need to pump out new versions all the time anyway.
    So really, point is, we're USED to this by now....its the norm. So spending precious time and ressources (even though Microsoft has a lot, they still don't have unlimited manpower) on something that ultimately, will be for nothing: everyone will have to recompile for new versions of the framework, directly or indirectly. (Heck, even between themselves: I remember when the Enterprise Library 3.0 came out... they said that the WCSF would work out of the box...then that it would work with a recompile...and even that didn't work! They had to come out with a new version).

  7. Avatar for Krenn
    Krenn March 3rd, 2008

    hgs - Think I found the scrollbar control in Vista for you. Try Control Panel -> Personalization -> Window Color and Appearance -> Open classic appearance properties for more options -> Advanced. Then select Scrollbar from the dropdown, and increase the size.
    That Classic view is pretty much unchanged from XP, but it's much harder to reach now. It's also not indexed for the Control Panel search...

  8. Avatar for hgs
    hgs March 3rd, 2008

    Thank you. How can it only be available in Classic View? Accessibility is a retrograde step? (I'll have to see if it affects present day style windows.)

  9. Avatar for Patrick Smacchia
    Patrick Smacchia March 3rd, 2008

    As a related link, you can read this blog post where I explain how to use the tool NDepend to detect all kinds of syntactic breaking changes in your code or in 3rd parties code:
    Avoid API breaking changes

  10. Avatar for David Nelson
    David Nelson March 3rd, 2008

    If I buy a component from a third party vendor and that vendor doesn't take the opportunity to upgrade their libraries during the extensive beta phases Microsoft typically offers, then I chose the wrong vendor.
    Adding a property to an interface is a pretty serious breaking change, and it should not be done lightly; but if it needs to be done, then concerns about third-party vendors who don't upgrade their libraries should not stop it from happening. Until Microsoft gets over this phobia of breaking changes, the .NET framework is at serious risk of becoming hopelessly mired in the mistakes of its own past. That would be a terrible end for a platform which still has so much potential.
    Breaking changes aside, ABCs are more often than not simply not appropriate. We all learn early on about inheritance and polymorphism; but hopefully we also learn that in most cases composition is more appropriate than inheritance, since the number of "is-a" relationships in most real-world applications is simply not very large. But composition requires interfaces. I am not going to compromise the design of my object model because the official Microsoft guidance is to use ABCs instead of interfaces, especially when I know that the justification for that guidance is an irrational fear of breaking changes.

  11. Avatar for Torkel
    Torkel March 3rd, 2008

    I think you are making a mistake. The pain of a breaking change is acceptable. Please reconsider!

  12. Avatar for Ed
    Ed March 3rd, 2008

    You are overstating the issue with 3rd party libraries.
    If I am implementing a 3rd party library, its compatibility is only an issue if I want to use that library AND use the newest version of the framework. An application hindered by many closed-source, 3rd party libraries is likely not a good candidate for immediate upgrade to the newest framework version.
    Listen to your customers.

  13. Avatar for Haacked
    Haacked March 3rd, 2008

    When I was a consultant, I've experienced clients who were using a key third party library for which the author went out of business and they didn't have the source code.
    I think readers of my blog don't realize that they are in the cream of the crop when it comes to source code management etc... ;) To them, breaking is fine.
    But I would contend that to the vast majority of clients out there, breaking changes is a big problem. I could be wrong. But please consider that so could you.

  14. Avatar for Haacked
    Haacked March 3rd, 2008

    In any case, while the MVC framework is still in the preview stage, we're breaking it left and right. ;)
    I don't think I can change our policy on breaking changes. I assume if we hear overwhelming feedback that breaking is fine, we might change it. But we've already heard overwhelming feedback against breaking changes as much as possible. So you have a big hill to surmount convincing people here that changing an ABC to an interface is worth ignoring the huge customer base asking for us not to break so much from release to release.
    When the next MVC preview is released, I'd also love to hear specific issues you are running into. I feel there's a lot of theorizing that it's going to suck that we have ABCs for the HTTP intrinsics, but I need to hear about specific real problems with it. Scenarios cut-off. Etc...

  15. Avatar for David Nelson
    David Nelson March 4th, 2008

    Whenever I see a MSFTie blog about backwards compatibility and breaking changes, the overwhelming majority of responses are in favor of relaxing the extreme stance toward breaking changes that .NET has exhibited so far. Yet you say:
    "to the vast majority of clients out there, breaking changes is a big problem."
    "we've already heard overwhelming feedback against breaking changes as much as possible."
    Where is this feedback coming from, and why doesn't anyone else in the blogging community have visibility into it?

  16. Avatar for Andrew
    Andrew March 4th, 2008

    Which customer base is that? Is it the same one you're targeting with ASP.NET MVC?

  17. Avatar for Haacked
    Haacked March 4th, 2008

    @David Nelson the vast majority of developers don't read my blog. :) I tend to think the more advanced devs are the ones reading my blog. The ones who care about this sort of thing.
    @Andrew I guess we'll find out soon. The next preview of MVC has a lot of breaking changes. It'll be interesting to hear complaints about that. (We can break now because we're still in preview format).

  18. Avatar for David Nelson
    David Nelson March 4th, 2008

    I'm sorry, but I think you just made my point for me. If the more advanced devs, "the ones who care about this sort of thing", are the ones reading your blog, and they are telling you that they are not overly opposed to breaking changes, shouldn't that tell you something?

  19. Avatar for Evan
    Evan March 4th, 2008

    I can't disagree with your assessment of the "Microsoft customer base" since I have little insight into the forest, but as one of the trees, I agree with a lot of the other comments. Breaking changes to 3rd party libraries is a non-concern for me. I could say why, but many of my reasons have already been stated here.

  20. Avatar for Haacked
    Haacked March 4th, 2008

    @David Nelson I guess I need to find out if the devs reading my blog are a "representative sample" or not.
    Right now, even if I wanted to ship a breaking change, I don't think I could. So if I shipped an interface today, it would be frozen unless I can convince the powers that be that being free to break is in the best interest of our customers.
    I don't have the data (other than comments on my blog) to make that claim over what others who have been here longer than me have experienced regarding breaking changes.
    I'll dig into it a bit and see what I find out.

  21. Avatar for Ayende Rahien
    Ayende Rahien March 4th, 2008

    Then ship an interface today, what is the problem?
    Are you familiar with the term: Maybe the horse will sing?
    If you will have to have IHttpContext2 in two years, why is this a concern?

  22. Avatar for Eamon Nerbonne
    Eamon Nerbonne March 4th, 2008

    Well, if by HTTP intrinsics you mean ASP.NET basics such as HttpContext, I've run into issues with those being classes, and not a multitude of small interfaces.
    A caching helper was using a number of HttpContext features. Turns out, the caching helper might be useful elsewhere, but is written to access HttpContext. If I could have merely reimplemented the appropriate interface (say, the caching) I could have wrapped the original instance without problem or code-change, and referred it to the non-web back-end in the non-web case. Now, it means re-inspecting the code for it (which fortunately is available), and refactoring it to use a home-grown interface. That's a really unfortunate solution, however, since it means there will never be any sort of modularity here. This particular home-grown interface is only used in one project, and there are no drop in replacements, nor other consumers.
    This is probably not the best example, but merely one I happened to run into recently.
    For that matter, let's say I have a nice IHttpHandler somewhere, which happens to have been written for the web, but is useful elsewhere - I can't call that thing without a reference to an HttpContext, and HttpContext is a class so I can't safely reimplement useful features. Furthermore, it's huge; rather than being a composisiton of mostly independant interfaces, it's one big object with potentially a lot of black-box "magic" happening inside - who knows? Certainly, it's unfortunate.
    Basically, the [i]core[/i] programming tenet of encapsulation is violated by using ABC's. They fail as an encapsulation mechanism since you cannot replace them where needed. The very fact that they have a real namespaced name, with implementation bits lying around, means that [i]replacing[/i] that implementation is impossible - at best you can subclass; but without knowing the implementation details, it's a random bunch of guess work - who knows what side effects the constructor has? How easy is it to work around the explicit interface implementation you can't override? What happens if some functions can't be overridden by (mis)design? It's much, much harder to make software in well-compartmentalized bits if the core is so inflexible.

  23. Avatar for Ed
    Ed March 4th, 2008

    >When I was a consultant, I've experienced clients who were using a key third party library for which the author went out of business and they didn't have the source code.
    Why are they forced to upgrade? It is absurd to believe that an application tied to closed-source, legacy code that will never be updated is a good candidate to update to a new version of a key framework.
    Using third-party libraries is a design decision, where you say that you are willing to risk the possibility that your design decision precludes upgrading of the framework version.
    Do not make the rest of us suffer with poor framework design simply because some organizations choose a design that is inherently less maintainable.

  24. Avatar for Karthik Hariharan
    Karthik Hariharan March 4th, 2008

    Would it help if we started on an online petition to ScottGu entitled "Let Phil break the MVC code" ? :)

  25. Avatar for Joe Brinkman
    Joe Brinkman March 4th, 2008

    One thing that is missed in this whole thread is that Phil is talking about a general design philosophy that extends beyond a single Interface or ABC. It is easy to say that a specific feature should be implemented as an Interface and breaking change risk be damned - we'll just recompile. But if the philosophy espoused by the TDD crowd were applied accross the board, as many here are suggesting, then the result would be complete instability. When you multiply the risk posed by an interface times the number of interfaces that were implemented instead of ABCs, then the overall risk goes up dramatically and you almost guarantee that every release would break every existing application. Not exactly a winning formula for platform adoption.

  26. Avatar for Ayende Rahien
    Ayende Rahien March 4th, 2008

    I am practicing this approach, and I am building some widely used frameworks.
    Somehow we escape the problem on instability.

  27. Avatar for Francois Ward
    Francois Ward March 4th, 2008

    Joe, there is a balance to be had, for sure. As pointed above by David, people are in favor of -relaxing- the backward compatibility constraints, not eliminating them. How much would we have benefited if backward compatibility was broken for ADO.NET to have it use nullable types directly? Now we have a bunch of extension methods as a crunch for it.
    What it means, is that going that route, no matter what, with certainty, the .NET framework is doomed. It may be later rather than sooner, but be it 5 or 10 years from now, my application will, for sure, have to switch to a different framework and language, because the one I'm using now has a bunch of tricks,hacks and design choices that made it a mess to keep backward compatibility (.NET 3.5 is the best example of worked this time...but if they use the same strategies next time...what a mess! Everything will be extension methods and abstract classes implemented in separate assemblies?!).
    Thats just an example though. Its part of why .NET is so popular over Java: Java made that mistake.
    So between having things be a mess every so version, but end up fresh and keeping up with the time, OR having no issues with backward compatibility, but having to restart from scratch in the future because .NET simply couldn't keep up with changes because of an overly conservative policy, I pick the former.

  28. Avatar for jdn
    jdn March 4th, 2008

    You can't really compare the number of people who use the frameworks you are building with those built by Microsoft. It's orders of magnitude different.

  29. Avatar for Ayende Rahien
    Ayende Rahien March 4th, 2008

    Your point?
    The people that uses my stuff are a subset of the CLR people, that is by definition.
    That is a large enough number to get a statistically meaningful result out of.

  30. Avatar for jdn
    jdn March 5th, 2008

    Compared to the number of people who could/would use IHttpContext/HttpContextBase? Not even close, the comparison is meaningless IMO.

  31. Avatar for Ayende Rahien
    Ayende Rahien March 5th, 2008

    I used the term statistically meaningful result very carefully.

  32. Avatar for Joe Brinkman
    Joe Brinkman March 5th, 2008

    @Ayende - My experience on DotNetNuke is that every breaking change has affected dozens of third party vendors and 10s of thousands of users. While the project may be able to deal with the added support issue, this has created undue burdens for the vendors who may not have the resources to drop everything else to release an updated version of their product to coincide with our release schedule.
    Also, it is important to note that not all frameworks have the same constraints. When your framework does not include a large 3rd party vendor community then it is easier to deal with compatability issues, however when your breaking change affects component vendors who build on top of your framework, then the "pain" becomes magnified for both the vendors and the end users.
    It would be irresponsible of Microsoft not to take backwards compatibility into account when designing their frameworks. One of the advantages that they enjoy over almost every other development platform is that they have a strong and vibrant component vendor community who provide a ton of value to end developers who don't have to recreate the wheel on every project. If you don't think that is a big deal, just look at all of comments around WPF and Silverlight 1.0 where developers have complained about the lack of components even to the point of waiting to develop on the platforms until the component vendors had caught up.
    If you want to kill off the component vendor community then just start releasing frameworks that don't take backwards compatability into account. You will quickly make it an unprofitable business.

  33. Avatar for Joe Brinkman
    Joe Brinkman March 5th, 2008

    Speaking of breaking changes: has some renedering issues in IE8. I am sure it will just require a simple re-compile of the CSS ;-)

  34. Avatar for David Nelson
    David Nelson March 6th, 2008

    No one is saying that Microsoft shouldn't take backward compatibility into account. Obviously breaking changes are a huge pain both for component vendors and for end users. What we are saying is that they need to be giving less weight to backward compatibility issues and more weight to the future maintainability of the framework. Breaking changes cause pain once; leaving bugs or poorly designed APIs in the framework causes pain forever.
    Your tongue-in-cheek comment about Haacked's rendering issues in IE8 brings up a perfect example. What if 10 years ago the major browsers had refused to change their rendering engines because it would have caused existing websites to "break"? Can you imagine the mess we would be in today? This article exactly mirrors the conversation we are having; in the end, the IE team decided that having a properly standards-compliant browser was more important than existing websites being able to rely on non-standard behavior in IE7. The .NET team needs to take a lesson from this decision.

  35. Avatar for Ayende Rahien
    Ayende Rahien March 6th, 2008

    Please do not twist my words.
    I never said that backward compatibility wasn't important. I think it is _very_ important.
    I have actually suggested a way to handle this in a way that allows you to have both good design and maintain backward compatibility.

  36. Avatar for Joe Brinkman
    Joe Brinkman March 6th, 2008

    @Ayende - I am not twisting your words. I am puting them in the context of the blog on which you are responding and my earlier comment to which you were replying.
    I completely agree that there needs to be a balance, but other than the last 4 or 5 comments, I don't seen anyone advocating balance. I see a bunch of comments on why Interfaces should be favored over ABCs and why breaking changes are acceptable.
    In fact, in his first post advocating relaxing the restriction, David states very clearly that he does not have access to the data on how much of an impact relaxing the philosophy would have to Microsoft or to their customers. So if the issue is on how relaxed Microsoft's stance should be WRT this issue, then who is most likely to have the applicable data on what the correct balance should be? I would argue that 20 years of experience in dealing with Interfaces in C++ and COM, and 10 years in .Net has taught Microsoft quite a bit about what their customers will accept and won't accept in terms of breaking changes and Microsoft's ability to perform longterm maintenance on frameworks using interfaces. Microsoft has not always had a philosophy that shied away from using interfaces in favor of ABCs, that is something that was developed over many years of getting beat up by customers and vendors.

  37. Avatar for David Nelson
    David Nelson March 6th, 2008

    "other than the last 4 or 5 comments, I don't seen anyone advocating balance. I see a bunch of comments on why Interfaces should be favored over ABCs and why breaking changes are acceptable."
    Precisely. Interfaces should be favored over ABCs. Not used exclusively, favored. People are in fact advocating balance, and in particular are advocating interface over ABC in this particular circumstance. Saying that those of us who are in favor of relaxing the back-compat restrictions actually want Microsoft to "not take backwards compatability into account" is an exaggerated attempt to polarize the issue, and does nothing to further the actual discussion.
    In response to your particular argument, I would argue that 15 years of dealing with Win32 should have taught Microsoft quite a bit about the perils of leaving broken and/or poorly designed implementations in a long-lived framework. Do you really want .NET to look like Win32 in another 5 years?

  38. Avatar for Andrew
    Andrew March 6th, 2008

    I wonder, what other interfaces should we expect to be replaced by ABC's?
    If the argument is to favor backwards compatibility here, then what other base level interfaces will be changed?

  39. Avatar for Reddy
    Reddy March 6th, 2008

    NHibernate 1.2 release deprecated existing interface and introduced two new interfaces.
    ILifecycle and IValidatable interfaces
    The ILifecycle and IValidatable interfaces were deprecated in NHibernate 1.2 and moved to the NHibernate.Classic namespace. The Hibernate team does not consider it good practice to have domain model classes depend upon persistence-specific APIs. NHibernate 1.2 applications should use IInterceptor interface. Existing applications may continue to use ILifecycle and IValidatable.

  40. Avatar for Ayende Rahien
    Ayende Rahien March 6th, 2008

    I can top that, for NHbiernate 2.0, we have deprecated a namespace.

  41. Avatar for Morten Mertner
    Morten Mertner March 7th, 2008

    I can't see the logic behind choosing an ABC over interfaces at all.
    With interfaces it's much easier to do versioning because you can extend the old interface with whatever new functionality you need by creating a new inherited interface. If need be, deprecate methods on classes that implement the old interface and direct users to the newer methods, but don't change the existing interface definitions.
    It should be safe to update implementations to return the newer interface, as it is type compatible with the old interface from which it inherits.
    The only drawback to this approach is that you might end up having an IHttpContext2 interface, if you run out of appropriate names to use for the newer version. But this is primarily a cosmetic issue that has little impact on functionality.

  42. Avatar for David Nelson
    David Nelson March 8th, 2008

    The problem with that is that you can't actually add functionality by adding a new interface, since a) interfaces cannot contain any implementation, and b) existing classes won't automatically implement the new interface. With a base class, you can add new features which will propagate to existing child classes automatically. Also, since existing APIs will be using the old interface instead of the new, this can result in a lot of downcasting. These are the advantages that ABCs have over interfaces that Microsoft has used to justify this particular design guideline. And they are legitimate considerations. However, in my opinion, and obviously in the opinion of many others here, they are not enough to overcome the downsides of using ABCs in many if not most cases.

  43. Avatar for Morten Mertner
    Morten Mertner March 8th, 2008

    I was kind of assuming that when you provide a new interface you also provide an implementation for it, and hence you can add functionality by providing new interfaces (inherited or not). The freedom to have base class changes propagate remains even when interfaces are used.
    Making a functional change that requires changing method signatures or the introduction of new ones affects subclasses of an ABC and interface implementors equally. The key difference between the two is that with interfaces it is much easier to remain backwards compatible even in the face of major changes, because you are free to replace the underlying implementation entirely.
    Downcasting should also not be an issue. If the interface consumer is aware of the new interface and wants to access it directly, this requires changes in the original code and hence would be better solved by accessing new properties or methods that return the appropriate new interface directly. Introducing such in a derived interface would be a non-breaking change for existing client, who can continue to work with the old interface.
    I don't get it. I must just not be clever enough :-)