On Jan 25, 2014, at 12:55 PM, Simo Sorce <s...@redhat.com> wrote: > The reason is simple: lot's of software *changes* data as part of its > normal functioning, including and often in rollback-incompatible ways. > > You cannot assume that upgrading a program that uses a database X from > version A to B can still work if you keep database X unchanged and then > rollback from B to A. Lot of applications apply changes to database at > upgrade time, either in the rpm scriplets or automatically as soon as a > new version binary is run.
I wouldn't ever expect this with a minor version or security update. I'd consider it a complete betrayal of software versioning to do this. In fact in certain instances of major version changes, downward compatibility of the file format is expected. > It is basically impossible to find applications that handle the case > where you downgrade, in any more graceful way than punting and failing > to start in the *good* case. In the bad case they start and trash the > database. I guess I'm not really following. Do you have a for instance? Because off hand this sounds like a kind of sabotage to me. If it's throw away database info that can simply be reconstructed I'd probably tolerate it. But for that matter, such things should go in an defined cache location so that it's not even being backed up. But important user data having it's format updated in a way that makes it incompatible with the previous minor version (same major version)? I'm snickering at the language that would ensue in the proprietary software world, if I'm not totally confused about what it is you're suggested is fair game. It'd be the sort of language you wouldn't want your teenager or grandmother to hear. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
