Breaking Changes: past, present, and I can't speak about the future

Ok, so a large part of my job is finding breaking changes and helping make sure that they get fixed. These changes are classified as backward or forward compatibility breakers. Backward compatibility means a newer version of the .NET FX can run older apps and forward compatibility means an older version of the .NET FX can run newer apps. There are currently two released versions of the .NET FX out there (excluding service packs) these are 1.0.3705 and 1.1.4322 or V1.0 and V1.1 for short. 

There are a bunch of apps out there built on V1.0 that people are upgrading to V1.1. Keep in mind that you have to be aware of the breaking changes between these two versions!  https://www.gotdotnet.com/team/upgrade/apiChanges.aspx gives you a list of API changes. To read the list after you've downloaded it, the left hand column represents removed API's and the right hand column represents added API's. Breaking changes are highlighted in Red. If you find an API has changed, you likely can get around the problem by updating your

https://www.gotdotnet.com/team/changeinfo/default.aspx gives a list of other breaking changes in both forward and backward directions. If you've upgraded to V1.1 and are encountering problems, check here. This is a great resource as it shows workarounds for a lot of common problems that I've seen being asked. 

Obviously, our focus is predominantly on maintaining backwards compatibility. This makes sense, as you can't expect to take advantages of new features and expect your code to run fine on an older version of the FX where these features did not exist. At the same time, the line is tough to make - what about improvements?

Sometimes fit and finish and improvements to the overall quality of FX are somewhat hindered because of the requirement to maintain compatibility. A great example of this is making additions to enums. Trust me, there are a ton of extremely intelligent folks here who debate the issue of moving forward and making something great vs keeping things compatible to no end. In the end, rest assured we're doing our best to satisfy as many needs out there as possible.

This posting is posted “as is” and guarantees no warranties and confers no rights.

Comments

• Anonymous
  February 20, 2004
  Personally, I say that anything and everything should be broken for ths sake of improving the system. I've never seen an effortless upgrade in my development lifetime. If I want to run on a different runtime, personally, I expect to have to make changes to my code to improve performance and take advantage of new systems.
  
  But that's just me. I'm told that I'm in the minority on that one.
• Anonymous
  February 21, 2004
  I agree. If improvements (or fixing the mistakes of the past) mean breaking things, so be it.
  
  Disk-space is so cheap these days, if you're unwilling to port and deal with these "breaking changes" just make a copy of everything into your app's directory and run things side-by-side.
  
  I think you guys spend too much time worrying about trying to handle every single case so as not to break anything.
• Anonymous
  June 08, 2009
  PingBack from http://cellulitecreamsite.info/story.php?id=8599