Leave old binaries around after upgrade

[bgentry]

@will & @fdr brought up the great point that auto-upgrading could really suck if you got upgraded to a broken version and couldn't easily get back to a working one, especially if you're in the middle of a workflow. This differs from Chrome auto-updating in that you'd actually have to restart your browser, whereas hk restarts after every command.

One possible solution would be to leave a cache of the most recent binaries available somewhere for emergency usage.

Not sure if this makes sense or seems totally wrong, just wanted to bring it up as an idea.

[kr]

Yeah, definitely something to be sensitive to.

Are we worried that the upgrade process might result in a broken binary, or that intentional changes might cause disruption? I'm inclined to treat those as two separate problems.

For the problem of actual brokenness, perhaps the right solution is to reinstall from scratch from the website. The flow of installing from scratch is a core part of the hk experience, and worth putting a lot of effort into streamlining, so it seems unlikely we'll be able to do much better than it in the case of a broken update. That flow will also be exercised regularly (with new users all going through it), so less likely to bit rot than a "rollback" feature in the self update process.

I think it's also worth spending a great deal of effort making the update process more robust in the first place, including defensive measures such as ensuring the new binary can execute successfully (e.g. hk version) before moving it in place.

For the problem of causing disruption as a result of intentional changes, I see a few ways to address that:

• provide a way to roll back recent self updates
• provide a way to disable or defer self updating for a time
• design around the problem:
  • provide relatively stable interfaces
  • document which things should and shouldn't be relied upon in automatic processes
  • introduce changes gradually and incrementally; avoid abrupt large redesigns (this is more for the benefit of human users)

FWIW, the existing toolbelt gets away with autoupdating unconditionally. Changes in behavior have caused problems in the past, but I believe for most users this is outweighed by the benefits of updating. IIRC, the current toolbelt has a way to disable automatic updates, but not to roll back. I don't know how much we should lean on toolbelt design here; @ddollar do you care to weigh in?