kmail downgrade wipes dimap cache

Unfortunately downgrade scenarios are not supported, neither by KDE, nor Kubuntu, nor Canonical.

We certainly can discuss whether a downgrade is sometimes necessary and whether KMail should detect that you are trying to downgrade and whine you about it. But really, would you have the limited time developers have rather see spent on assuring that downgrades work or that upgrades work?

Marking invalid.

Your decission is fair, of coures, just two remarks still:

I wasn't asking for sophisticated data migration and stuff, just the normal check
that an expected format version doesn't kill user data. Shouldn't cost much to implement.

Second, I strongly believe that even basic support for downgrading WOULD immensly
increase the value of any open source software. Recall that I wasn't performing the
downgrade just for fun, I was forced to do so by bug 338669 (which wasn't even considered
critical, so we must face: this is just a normal bug as there are millions of out there like it).
Currently, upgrading to a new version of XYZ (e.g., Ubuntu) is a game: you can win but
you can also lose. If losing means: game over, there is no joy in using the software.
If you still have a chance to move to a safe place after upgrade has screwed up your
system, earth (well your computer ;-) would be a much safer place.

Compare the current situation with software in the previous century which didn't have
an undo button. Something we just wouldn't accept nowadays. Mistakes happen at all
levels. We'd better have means to recover from them. I don't think I'm exagerating here.

As I said, it is a matter of resources. If we had enough human and computing resource we would support up and downgrading from all supported Ubuntu version to all other supported Ubuntu versions. But we don't have that.

It might sound incredibly easy to implement a simple data check, but that simple data check depends on humans to tell the checker between which versions an incompability was introduced. Then again humans make errors, so you need a sophisticated computing system to back that up and either run daily up and downgrade checks and then somehow evaluate the results to again poke a human who has to validate that indeed there is an incompability and that the computing system (which was also created by a human) didn't mess up, or the computing system is indeed intelligent enough to evaluate the source code itself to trace changes that could cause incompability, still using the above documented chain of triggered human check-ups though.So, that is what needs to be done on an application level, but most applications use libraries which are shared across multiple applications and those applications might do completely different things with the same set of libraries, so you'd need to duplicate and adapt the process for each application, each library, simply put, each part of the software stack independently.

This is just a very raw picture of what would be needed to ensure downgradability, in fact some stuff goes far beyond what can be automized without an artificial intelligence, so in order to ensure the whole Ubuntu stack works, you probably need to lock all of northern america away for a month and let them test everything manually.

Amongst other reasons, this is why almost no software project, company or single developer even claims to support downgrades, long ago the industries faced the fact that it is pretty much impossible and just declared it a standard that there is no support for downgrades.

And that is why a network/system administrator will always do test upgrades (clone the data and try it out), ask google for known issues etc. etc. and also why any home user should backup their data, especially before upgrades.

That said, a data backup is one of the means to recover from a mistake :P So, if the Ubuntu upgrade would ask you and assist you in doing an backup, that would be very good (and in the long run that will happen).

Anyway, as a general rule: downgrades from 4.y to 4.x are never compatible, there will always be at least one component that changed the config layout or the file format etc.
Down from 4.x.y to 4.x.x is usually a pretty save bet, but might also cause issues, very unlikely though.
For Ubuntu it is never save to downgrade, there are too many things involved in the software stack, so you are bound to experience breakage at some point (also with each Ubuntu release you get a new KDE, so the first rule I mentioned will always apply).