ISV/VAR/SI: Speak now, or forever hold your peace!

  • Artykuł

On two life altering occasions I heard that phrase spoken, and writing it down still makes me weak in the knees. On the first occasion, I wish someone would have spoken up. But I digress ;-)

 

On several occasions I have conversed with customers on the subject of versioning and compatibility. Both subjects are complicated to understand and difficult to address in the software engineering realm.

 

For those who read my blogs, or have heard one of my Webcasts, it is evident that I am passionate about this subject, in particular as it relates to independently versioning dynamic components (i.e. Add-in’s, Extensibility, Public API’s, …). Compatibility also factors into this equation. I could tease apart the two subjects but I would like to hear your thoughts on both versioning and compatibility.

 

I was recently reading a blog entry from Jason Zander. He has a wealth of information and I highly respect him. I’m not just saying that because he is in my management chain and its review time J In Jason’s post on, “Red Bits and Compatibility”, he has a link to Soma’s post, where the question is asked about your opinion on your expectations and thoughts on platform compatibility. The overwhelming response to Soma can be summed up in the following comment - “There is absolutely NO reason to maintain backwards compatibility with previous versions of .NET with new versions”.

 

So the question I have for you (remember speak now … ;-) is whether ISV’s feel differently. I don’t plan to seed the conversation beyond that. Remember, you can reply anonymously.

Comments

  • Anonymous
    June 10, 2006
    I care about backwards compatibility. I want to be able to develop on 2003, load into 2005 and still have it work. I can then take advantage of new functionality in the new .Net on my functionality or I can slowly refactor my code to use the new functionality. I'm currently stuck on VS6 for most of my development work because the cost in time of moving to 2003 is massive and unfeasible. I think its unreasonable to say "We don't have backwards compatibility so if you want to use this one bit of new functionality/new IDE you have to spend the next 6 months updating your application".

    Side-by-Side .Net installs solves the problem of shipping an application on an old .Net version if you never intend to update the application.
  • Anonymous
    June 13, 2006
    I think that non-breaking backwards compatibility should only be maintained absolutely between minor versions (2.0 => 2.1).  Between major versions the engineering team should not be free to break compatibility if needed to produce a better framework and a better runtime for everyone’s benefit.  Why stick with a bad design just for unnecessary compatibility.  

    My team maintains huge projects that we build for very large organizations. If we move to a new framework version in an existing app, we do it for new features and expect to have to refractor anyway to take advantage of them.  

    I would only ask that when compatibility is broken we are given very clear documentation on every breaking change and how to do the same thing in the new version.  If we have good docs we can modify our apps as necessary.  That is what we do for a living after all.

    Side-by-Side .Net solves the runtime problems with breaking compatibility.  Give the design team the freedom they need to give us a better framework.  We’ll ship the version we need with our apps.
  • Anonymous
    June 14, 2006
    Hmmm.. Difficult question. I think that I would prefer backwards compatability on a source code level.

    Meaning that I want source code created under one version will compile under a newer version.

    I can see the advantages of not ensuring backwards compatability, but I think the disadvantages greatly outnumber them.
  • Anonymous
    June 09, 2009
    PingBack from http://jointpainreliefs.info/story.php?id=1947