+972 52-548-6969
What happened to backward compatibility?
I'm not so sure how I feel about it, but it was annoying enough for a blog post. For a very long time, Microsoft has had some really annoying policies around their code because of versioning and backward compatibility concerns.
On the one hand, it could be really frustrating, because it hindered progress. On the other hand, it was very reassuring, because existing code could be relied on the continue working.
We are working now on RavenDB 4.0, and I took a peek at MVC 6 (internally in RavenDB we are using Web API for the past several years), which is supposed to be the replacement for both Web API and ASP.Net MVC. And again, it is great that there is a single programming model, and I saw that there are compatibility shims in place to help the upgrade process, but they are expensive in term of perf, and they don't go all the way.
I wonder if this is the case because web applications are frequently short lived, in terms of development cycles. That plays relatively well to this kind of model. You generally wouldn't need to move large codebases between major framework versions.
Comments
I think Microsoft has already articulated throughout 2015 that Nanoserver, CoreCLR and ASP.NET MVC 6 is a reset of the platform, so most applications are unlikely to be upgraded as-is from 5 to 6, but instead modules of an app can happily have ASP.NET MVC 5 and .NET 4.6 living side by side with MVC 6 and CoreCLR. So backward compat is less the issue, more side-by-side and integration the approach. It's a similar story in many ways to Angular 1 and Angular 2.
this is software, sometimes you have to move forward.
same as older IE versions support is dropped, I think the same will be here. for the long term, I believe many of the parts will move to the CoreCLR platform, which is a good thing because it allows to run on cross platform, and also allows to frequent update of the framework parts.
I don't think there's an issue unless ASPNET4/MVC5 stops being supported, which is unlikely to happen in the next 5 years. There would be a compatibility problem if the next Windows Server didn't support MVC5 and MS forced you to upgrade.
Haven't seen more long living than enterprise ecomerce web apps, tens of years, and counting.
This annoyed me as well. I don't accept that our only options have to be allowing our system to wither on an older framework, limp along shimmed onto the current one, or "migrated" by basically rewriting them. What annoys me the most is that it was very clear, from early on, that migration was going to be bolted on at the end. There were long forum posts asking for the migration strategy early on (which amounted to: we're too busy figuring out how awesome this thing is we're building, we'll figure out migration when we're done).
They decided not to include backwards compatibility or migration as a design consideration, so we have a platform that is not backwards compatible and has a bolted on migration strategy. It would be interesting to see something comprehensive from the ASP.Net team on who they think their target market is., how often they are writing new applications, small sites from consulting gigs (I've still never gained anything from scaffolding?) versus enterprise apps that will never upgrade versus large evergreen platforms that keep their technology up to date. And whether that has data behind it.
I see this quite a lot with JavaScript frameworks as well. Andy mentioned Angular, I remember DataTables introducing some breaking changes by changing the class names. The migration plan for Foundation and Bootstrap often require a rewrite. It can be quite a pain when you need a bug fix in a newer version.
Comment preview