Electron-builder: Staged rollouts

[ir-fuel]

More of a question than an issue, but would it be possible to integrate staged rollouts in electron-builder? Is it technically doable?

[develar]

Planned. PR or reasonable donation can increase priority. Please read below details:

develar [8:10 AM]

completely separate/independent side project from electron-builder

This task is going to be implemented as part of electron-updater project. You can add required field to update info (% of userbase) and implement it as in the Squirrel.Windows — https://github.com/Squirrel/Squirrel.Windows/pull/666/files

I am happy to accept PR.
GitHub
Staged rollouts by paulcbetts · Pull Request #666 · Squirrel/Squirrel.Windows
This PR implements staged rollouts, where a certain percentage of your users will get the newest version of your app. We do this by adding a magic comment to the RELEASES file - unfortunately, beca...

simplyahamzing [10:47 PM]
Oh this looks great

[10:50]
But I was also thinking of something that would allow you to specify % of userbase and have that % grow over an interval. Basically I'd want to release in cohorts and allow the user (developer) to control the time between when the next cohort was given the app. So basically if you release to 10% and then 2 hours later, 20%, and then you notice an increased amount of bugs in your error tracker, you can pull the switch on the release.. Like say pause it; address concerns; and attempt to redeploy it...

simplyahamzing [11:11 PM]
I was a thinking a stand alone server and separate npm module that talked to server before the auto-updater started would allow for more control

[11:12]
Unless I'm misunderstanding how the Squirrel PR because it seems the roll out % would have to be hardcoded

----- June 2nd -----
develar [7:34 AM]
How it is implemented in the Squirrel.Windows:

1. Each user has some unique generated persisted id.
2. If update info from server contains % of userbase — this id is used to check is user falls into the affirmative bucket.

So — yes, during publishing shoud be a way to specify this % of userbase to put into the update info file. Later you can simply edit this file (e.g. S3/Github releases — edit latest.yml to “then 2 hours later, 20%“).

Of cource — you can use some generic server and return any update info as you want (e.g. to provide easy UI to manage it across OS / arch / country and so on). Or not server, but some Amazon S3 rules.

[ir-fuel]

Define "reasonable donation"? :)

[develar]

100+ eur/usd will increase priority enough to fix in 1-2 weeks :)

[ir-fuel]

OK 👍

[develar]

@ir-fuel What publish provider do you use?

[ir-fuel]

I am still running an old version of electron-builder (I think 11.x) because you guys update faster than your shadow :)
I have an app on Mac and Windows, and on Windows I use NSIS. Everything is self-hosted on Amazon S3 (manual uploads to release builds)

[develar]

Details: https://github.com/Squirrel/Squirrel.Windows/blob/f63edb85d29ed6df9a3735690139442c87ebca01/src/Squirrel/ReleaseEntry.cs#L157

[develar]

Interesting — Squirrel.Windows generates name based guid, but getOrCreateStagedUserId is called only in the one place and only last 4 bytes is used.

[develar]

Next version of electron-updater will add header X-USER-STAGING-ID to some requests, so, someone can write smart solution on server. Client implementation coming soon.

[develar]

@ir-fuel Thanks for your reasonable donation :)

electron-updater 2.3.0 published.

Implementation equals to Squirrel.Windows, so, should work quite well. 2 unit tests were added. But please test it manually. Supported on all platforms.

Docs: https://github.com/electron-userland/electron-builder/wiki/Auto-Update#staged-rollouts

In the future maybe electron-builder will allow you to set staging percentage during build.

[ir-fuel]

When checking the docs it only talks about editing .yml files. Is it still working with latest-mac.json as I am currently using? I think I somehow missed when to use yml and when json.

[develar]

is it still working with latest-mac.json as I am currently using?

Since electron-updater 2.0 all shiny features available not only for Windows, but for macOS also. No more latest-mac.json — in the docs latest-mac.yml mentioned.

[ir-fuel]

Yes but my currently released software using older versions of electron-builder and updater looks for latest-mac.json I presume?
Anyway I just saw that both the json and yml file are generated, so I will first push a technical update so the updater is up to date and uses the yml file before pushing out a new release with lots of changes which can benefit of staged rollout.

[develar]

Yes, "backward compatibility" — both files are generated. To ensure that old clients will get updates.

[ir-fuel]

It's hard keeping up to date with this package. Development here is really fast :)

[develar]

It's hard keeping up to date with this package. Development here is really fast :)

electron-updater has only second major releases :)

As for electron-builder — granular releases allows you to safely update according to semver rules, no need to worry that next version will break your app :)