Explore ways how to make Electron adoptions less painful

[Tyriar]

[Tyriar]

Upgrading Electron is currently more difficult than we would like. The August release is a great illustration of the issues we can encounter, we were still on v1.6.6 which was done in the May release so we were jumping ahead several months worth of versions. We had previously done some testing in v1.7.x and found that there was a debug-related regression (electron/electron#9696) which was only fixed in v1.7.4.

Here's roughly what happened:

• Upgraded Insiders to use Electron v1.7.4
• Upgraded Insiders to use Electron v1.7.5 when it became available
• After several days on v1.7.5 we discovered that closing VS Code actually crashed it on Windows (command + <number> key behaviers #10188), this regressed in v1.7.4 which was required due to the debug regression
• We built Electron v1.7.3 with the fix for the debug regression backported

Maybe we could have caught these issues sooner, or even better have reported upstream and got them fixed faster.

One idea we've been throwing around is to set up a branch that upgrades it's Electron version and then CI builds and runs our test suites. This would encourage us to build out the smoke test suite. When and who would start testing these new versions, ie. when does it land in Insiders?

We should also try accepting new patch Electron versions more aggressively (1.6.6 -> 1.6.latest) as these should be lower risk updates.

[Tyriar]

/cc @bpasero

[Tyriar]

New release process we came up with: electron/electron#10558

The main idea I was pushing for was moving to SemVer and making minor and patch versions as low risk as possible to update.