HACKING.md: document major-updating Electron

HACKING.md

@@ -109,6 +109,21 @@ but is painful to do manually. Do yourself a favor and install a
   3. Here is [a screencast of how the live-reload experience should look like](https://user-images.githubusercontent.com/522085/120407694-abdf3f00-c31b-11eb-9ab5-a531a929adb9.mp4)
 - Alternatively, you can run both test processes in the same terminal by running: `npm run watch`
 
+## Major-updating Electron
+
+When a new major [Electron release](https://github.com/electron/electron/releases) occurs,
+
+1. Wait a few weeks to let it stabilize. Never upgrade Nativefier to a `.0.0`.
+2. Thoroughly digest the new version's [breaking changes](https://www.electronjs.org/docs/breaking-changes)
+  - If called for by the breaking changes, perform the necessary API changes
+3. Bump `src/constants.ts` / `DEFAULT_ELECTRON_VERSION` & `DEFAULT_CHROME_VERSION`
+4. On Windows, macOS, Linux, test for regression and crashes:
+  1. With `npm test` and `npm run test:manual`
+  2. With extra manual testing
+5. When confident enough, release it in a regression-spelunking-friendly way:
+  1. If `master` has unreleased commits, make a patch/minor release with them, but without the major Electron bump.
+  2. Commit your Electron major bump and release it as a major new Nativefier version. Help users identify the breaking change by using a bold **[BREAKING]** marker in `CHANGELOG.md` and in the GitHub release.
+
 ## Release
 
 While on `master`, with no uncommitted changes, run:
@@ -117,3 +132,5 @@ While on `master`, with no uncommitted changes, run:
 npm run changelog -- $VERSION
 # With no 'v'. For example: npm run changelog -- 42.5.0
 ```
+
+Do follow semantic versioning, and give visibility to breaking changes by prefixing their line with **[BREAKING]**.