On Sat, 2014-01-25 at 17:28 -0700, Chris Murphy wrote: > On Jan 25, 2014, at 12:55 PM, Simo Sorce <simo@xxxxxxxxxx> 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. And who ever said 'minor' version ? However I've done this with minor versions too with internal databases. There is no betrayal whatsoever, major versions are introduced when you make user-visible changes or you break an API/ABI, you do not necessarily change major version for some internal change. > > 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? At least 3 or 4 applications I am involved with did this kind of internal changes. > Because off hand this sounds like a kind of sabotage to me. No, it is just normal, everyday, software development. > 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. In some cases it is data that can be reconstructed, so all you need to do is to manually blow away the files and let the app rebuild them. In some cases that also have additional inconveniences. In some cases it is not data you can or want to throw away. > But important user data having it's format updated in a way that makes > it incompatible with the previous minor version (same major version)? So ? It is only visible if you downgrade which a lot of software do not support and explicitly so. > 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. ?? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
