Mr B's Guide to Upgrading Software
1. If it ain't broke, don't fix it.
So your program now handles file type X, so long as users input values for foo and bar, which they never had to do before. This is all well and good, but be sure to add some sort of a check so users are only prompted for foo and bar when they're using a file of type X. Adding new features shouldn't make it more difficult to use old features.
2. If it ain't broke, don't break it.
This should go without saying, but apparently a lot of developers need to hear it, so here it is: All features that worked properly in version X of your software should continue to work properly in all versions subsequent to X. Anything else is the opposite of improvement.
3. New user interface: Ain't nobody got time for that
I don't care how clever, ground-breaking, or intuitive you think your new UI design is, I don't want to learn it. If you've added new, useful features that necessitate a new UI, I may grudgingly admit the usefulness of it once I've gone through the learning curve, but I still didn't want to learn a new UI.
So what do users want in a new version of your software? Well, I can't speak for all users, just because some of them want really odd things, but in general, our desires are very simple. If you must upgrade your software (and we really wish you wouldn't), we want a new version that looks like the old version and does all the things the old version did, but crashes less often, takes up less space on our hard drives, and uses less memory when running. If there are other specific features we want from your particular program, we'll ask you for them - please don't just sit there and try to make up new features you think we'll like.