Always write plugins for the current version and keep the nightly builds from the upcoming versions in mind. Anything else doesn’t matter.
Edit As @toscho pointed out in a comment:
There might be some explanation needed to why it is that way.
- Because I say so.
- Plugins only need to be compliant with core because if all play with the rules, nothing will fail. If one plugin doesn’t play with the rules, then it has a bug. And that bug needs fixing and not anything else and not another plugin or theme.
- Users not updating WordPress is a result of buggy plugins that are used and can’t get abandoned in systems without a lot of work. As written in (2), that’s bugs you don’t have to care about. The bugs need fixing, not your plugin considering broken third party code.
- Legacy Code needs no support. It needs replacement. Not your problem.
- Things change on a large scale over major X.X versions. When you try to support previous versions, you often need different workarounds and lots of version checking. That is (a) a maintenance nightmare (b) increases the code base (c) makes unit tests impossible as they’ve to run on one version – not less, not more and finally (d) decrease server disk space and performance (in most cases).
- WordPress already has a very old code base that lacks improvements in lots of edges and corners. In short: WordPress is old, uses a not longer supported PHP version as its minimum and therefore you’re already supporting previous versions in much lower levels than in the public API of your application.
Now go ask yourself:
When you’re already supporting an no longer supported PHP version, why would you want to support an application that isn’t even supported by its creators?