@vesuvius: I faced the problem several times, both as a producer and as a consumer. This is what I think I learned so far (usually the hard way):
0) The diamond rule: data are forever. Your application may not survive v 2.0, but eventually (even a decade later) someone will have to port your data to some new app. Having a clean, consistent and well documented format will save you from some embarassment.
1) Always include a version header. Sooner or later you have to update the format, and having to sniff the version just sucks.
2) Avoid creating hard dependencies between your file format and your internal representation of the document.
3) Avoid any sort of binary format that creates a dependency to the platform you are using. Endianness happens. Among other beasts.
4) Avoid as much as possible creating dependencies to external proprietary formats you don't have your own codec for. That nice component may be free and widely available now... (Wang Imaging, anyone?)
5) Being able to load files generated by older versions of your program is a must, but the opposite is most definitely not. Yes, you can get this kind of compatibility through some clever hack, but your format will be messed up beyond belief (hello PDF, feeling the love yet?)
This pretty much sums it up. I would only stress that documents, and their format, are not just a byproduct of some code: they are the whole point of that code. This is why feature requests that involve a breaking change should start with -1000 points. It's not possible to turn them all down, but it's a good cause to fight for.