Skip to content
This repository has been archived by the owner on Dec 27, 2022. It is now read-only.

Auto Updates #149

Closed
bayleedev opened this issue Apr 13, 2016 · 7 comments
Closed

Auto Updates #149

bayleedev opened this issue Apr 13, 2016 · 7 comments

Comments

@bayleedev
Copy link
Contributor

After looking at how electron handles updates it looks like there are some ways to handle updates. It sounds like a common enough issue to be part of the boiler plate.

https://github.com/electron/electron/blob/master/docs/api/auto-updater.md

@carlosperate
Copy link
Contributor

I had a quick look recently on this as well. It seems like it would have to change the os x and windows installers to use squirrel, so a major change from the current workflow tools. Apart from those two platforms, there is no alternative for linux, so it seems like generating the deb file would remain the same.

Personally I would welcome the change, but I can understand if some boilerplate users would not want to package their apps with squirrel.

@szwacz
Copy link
Owner

szwacz commented Apr 15, 2016

Yes, I also see the value here. And for sure finally will have to wrestle with this problem. My main concern is that it should be also easy to unplug (turn off) and should be easy to plug into real server-distribution workflow without actually implementing it here (I hope this thought sounds sane ;) ).

Does someone who's reading my words use this boilerplate with auto-update? If so how many changes was required to make it work?

@black-snow
Copy link
Contributor

Damn, I need the auto-update right now.

Why don't we offer this as an alternative to npm run release as npm run release-squirrel or something like that. I don't see why one should use both at the same time - you either go one way or the other so you don't have to maintain two installers but just the one you prefer. We could also stick with a single npm run release and have a config flag that chooses between NSIS and squirrel.

@carlosperate
Copy link
Contributor

carlosperate commented Jun 9, 2016

I don't see why one should use both at the same time - you either go one way or the other so you don't have to maintain two installers but just the one you prefer.

The boilerplate would have to maintain two different installers.

@black-snow
Copy link
Contributor

black-snow commented Jun 9, 2016

Ain't this what the boilerplate is there for? Bundling stuff so that we as app developers ain't got so much to do?
Also I'd call this pretty mucg a must-have. Virtually any application has auto-updaters nowadays.

Will try hacking on this.

@szwacz
Copy link
Owner

szwacz commented Jun 11, 2016

This project's build process was designed when such packages like mentioned here: #172 weren't there yet, or were so immature that I was afraid of using them. Now I consider this part of electron-boilerplate a legacy, and I'm willing to switch into mainstream tools if it won't do harm to any of the current features this boilerplate has.

Any help in this area is greatly appreciated. I must start myself by getting familiar with that build tools and what they actually offer.

@black-snow
Copy link
Contributor

Can we close this issue?

@szwacz szwacz closed this as completed Nov 20, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants