Undoable Silent Autoupdate

Recently:

Something Aaron didn’t mention - What happens when a silent auto-update breaks something? Anyone that's had to do battle with the demo-pixies silently changing something just before an important demo hates the idea that something might be silently altering their rendering engine as they are opening their laptop on-stage.

PPK's issue basically comes down to testing older versions - how can I test version X-1, when it's just been replaced by version X. On the one hand with silent auto-update virtually everyone will be on version X, so X-1 isn’t important, however I don't think that removes all need for testing on X-1.

Solution?

We should have silent auto-update. It makes the Internet safer, and we badly need that. But we should also have a system that keeps old versions around for some period of time with a way for users to revert. Maybe there is then an entry in the help menu that allows users to say 'it broke take me back', and maybe a preference that configures the number of old versions left lying around.

I have a suspicion that many corporates turn auto-update off in order to test the updates batches before internal release (or to put it another way - it's a cost saving) Maybe with undoable silent autoupdate they would allow the system to work without getting in the way?

I'm a big believer in undoable silent autoupdates.

Posted by Joe Walker

Comments

Aaron Re: Undoable Silent Autoupdate

Thanks for the comment. I think just having a way to turn off autoupdates would suffice. People in the industry who want to control their configuration tightly could use this, but then they're taking responsibility in their own hands.

Joe Walker Re: Undoable Silent Autoupdate

So presumably from your post, you'd leave auto-update on? But next time you do a demo, would you remember to turn it off? Given that disk space is close to free these days, I don't think the undo option should be *that* complex. It would be nice if this feature was offered by installation packages though.

Aaron Boodman Re: Undoable Silent Autoupdate

Ah, I wasn't really thinking about the demo use case. It's true that nobody will ever remember to turn off autoupdate on all the pieces of software that could bite them during a demo. Undoable autoupdate is pretty tricky because the software is going to want to migrate its data forward to the new version. Lots of software is built with the assumption that you can only roll forward, never back. It's true that it is technically possible to support undoable updates, but I bet it practice the undo would be pretty buggy unless it was some sort of framework that the OS offered that was difficult to screw up.

Joe Walker Re: Undoable Silent Autoupdate

I guess you've got a number of tools:
1 schema-free data files
2 clone/upgrade (i.e. fork)
3 giving old app versions access to the user-data-api from newer app versions
4 support redoable undo as you mentioned

I would have thought that between those (particularly with #3) you could support most scenarios simply, although I totally agree it's not the same as simply clone/upgrade everything.

Joe Walker Re: Undoable Silent Autoupdate

I should have added - the purpose of this is to keep working and not to support parallel running, so maybe clone/upgrade is a decent and simple solution.

On roll-back, it is assumed that any changes the user made to their profile will be lost. Since the application is assumed to have been be broken by the upgrade there will presumably not be many user-initiated changes.

Comments have been turned off on old posts