We work hard to make DotNetNuke backwards compatible and anytime there are issues (pretty rare) we resolve them ASAP - the main thing to be aware of is that later versions have access to more functionality so you have to be careful about making assumptions with your code.

In general for module developers, they pick the minimum version of DotNetNuke they want to support and code against that (i.e. add that versions dotnetnuke.dll as the reference for the module projects i.e. most people have a solution file where they add the dotnetnuke site [which might be 5.0.2] and then add WAP projects for their modules, they then use this to build their modules but may only ever deploy and test to a dotnetnuke 6.0.2 site). This ensures that they don't use API calls that only existed in later versions. Best practices then say that when you package your modules you should add a dependencies node to the manifest to indicate the minimum version so that users dont install it on earlier builds and see errors (http://www.dotnetnuke.com/Resources/W... ) e.g. you might set yours up as so
<dependencies>
    <dependency type="CoreVersion">05.02.00</dependency>
  </dependencies>

Skin developers need to do something the same, but it's less restrictive as skins contain little code (though if you're going to use jquery you should register it programatically (http://www.dotnetnuke.com/Resources/W...)

---

Buy the new Professional DNN7: Open Source .NET CMS Platform book Amazon US