We have a desktop application which needs to expose API.
Some people say: API should have an abstraction layer so actual implementation can change in future versions.
Others say: API should be version specific. So an API which uses version X will only work with it. Version X+1 will also deploy the dll's of version X in order not to break existing usage. This is claimed to be aligned with how frameworks like .Net or Silverlight works.
What is your opinion?
Some questions that you should consider:
My opinion is that you should maintain API compatibility across versions if at all possible. Microsoft have achieved it, mostly, with Office and it's why there are so many add-ins, accessories and LOB applications built around them. I, for example, wrote an application on-top of Access XP that used Excel automation quite heavily and it works without error in Office 2010. That's what I call compatibility!
I have found that versioning an interface is a useful tool to implement breaking changes.
You should do your best to get your API interfaces right the first time.
When you have a breaking change (changing existing signatures, so client code must be recompiled), you must change the interface, and when you do so you can change the version. Non-breaking changes (e.g. adding new features to a different class) shouldn't change the version, if you can avoid it.
If you are using Net as a reference you should notice that they take a hybrid approach, they use a bit of both, do not confuse CLR version with NET version.
You should consider your app uses in order to find the answer for you.
My money is on mantaining API compatibility accross all versions as possible.
However there are drawback to that as well.
Regards
If you do decide to go version specific make sure you're very up front with your users. I've missed deadlines half a dozen times do to my vendors changing their web services without notifying me and having to scramble to come up with a solution
Use the idea of closed for modification, open for extension. Any parts of the API you expose should not change in future versions if at all possible. (Parts you don't expose can be modified, provided they still function the same). A programmer expects to use an API and have that code work for it's lifetime, without worrying about the version he is referencing.
Consider that in later versions of the API, you might expose new features that each user of your API might want to adopt - but he already has code written against the old version of the API. He should be able to plug in the new parts without rewriting his old code (Assuming the new parts don't rely on the breaking changes).
If there are breaking changes to be made, you should not remove the old way of doing it, but mark it [Obsolete], and give a clear message on how it should be updated to the newer API.