please can someone help get this feature started for the configurator
@frizzle101101: The title and text of your feature request are not clear at all. Can you please clarify or close?
Sorry i mean like when a release is released it goes up on the page as well as into an auto update database or something. Then a built-in updater in the configuration will alert the user of and an update and do everything for them so they do not have to download and install the new version every time
Now I'll have to go download the new version from the release page and will end up having multiple versions of the bf-configurator installed, so this would be nice.
@frizzle101101: So essentially what you are asking for is a notification to be shown telling you that newer firmware is available whenever you connect configurator to a board that isn't running the latest firmware?
What I think he means is an update for the configurator. In order to update you'll have to remove the old configurator (otherwise you'll get multiple versions of the configurator) right now and download a new one. What'd be better is having it auto update its self.
The actual installer (at least Windows/Linux) removes the older installation before installing the new version.
@timman2er: Auto-update, and in particular the ability to update by only pulling the updated js / html / css files for the configurator and not the 10s of MB of NW.js that they are wrapped in would be great.
@mikeller for me (or probably anyone else interested in adding this), it might be handy to list how updates are currently done (what server etc.).
@timman2er: Currently we only do full updates, packaged as installable packages / executables, and they are distributed through GitHub - so for automatic updates we'd probably have to come up with a new way to distribute. Maybe we could use the http://betaflight.com/ server that is provided and managed by @wind0r.
We're talking about auto update, but to be sure it`s user initiated by a press, after which everything is done automatically for them right?
Also, there seems to be documentation available for this already: http://docs.nwjs.io/en/latest/For%20Users/Advanced/Autoupdates/ .
There seem to be two we can choose from:
I think we'd best go with nw-autoupdater.
@timman2er: I think ideally the user would be given a choice between 'automatically update' and 'notify me when updates are available (we already do this), and let me install the update with one click (this is new)'.
Looking at oaleynik/nwjs-autoupdater and dsheiko/nw-autoupdater, they both seem to be working by downloading the entire installable package for each platform, and then starting the installer. This means that this won't improve things by much for our users, the only thing that is eliminated is clicking on the file to download, and then double clicking on the installer. The installer itself will still run like it does now.
Not sure if it's worth putting effort into this under these circumstances, this will still not be received well if we move to more frequent configurator updates, and then force users to download > 70 MB each time.
Well I think that modifying it based on only changed files would be best. It'd require to check a "last modified" timestamp like you have in windows folders and only changing those files.
Even if all the source files for the configurator were pulled in for every version change this would still reduce the size of the download by ~ 90% (~ 7MB source files vs. ~ 70MB for the packed NW.js installer).
Good point, but I think the following needs to be considered:
I just did a quick test, and the combined size of src/ and resources/ in a zip file is ~ 8 MB.
Well from the first comment today it sounds like you just want to pull src and resources, making that 8 mb. If that's so, how do we deal with nw.js updates?
The way we do until now - we ask the user to download / install the updated version - there is not really a way around that anyway.
I think that updating files based on whether it's modified or not would be a simple enough step from what's out now. If we were to move to more frequent updates, I think we should do so. It'd make a nice Github repo as well. This should make updating much less painful.
How would you detect if a file has been modified, short of downloading and comparing the files?
The ideal way is to have an "update_info" file with all the files of the version and the hash of each file. Then in local, downloading this file and comparing the hash with the local hash, is enough to detect which files have changed and download them.
@McGiverGim: That would work.
But the effort for generating this file as part of the build process, and then hosting it and all of the files for every release, and doing the comparisons and on-demand downloads will be considerable.
For updating electron apps there is https://github.com/GitbookIO/nuts and https://github.com/zeit/hazel .. which just use github releases as a backend.
maybe there also is something similar that just can be used for nw.js. then we do not need to do some homegrown solution. just updating the js files should be small enough.
True, the problem here is to store a tree with all the versions, for each operating system, in a server, maintaining this.
To me is not a problem to execute the complete installer for each version ;)
Ohh. Missed a post above where those soltuion for nwjs allready got named.
I dont get why a tree needs to get stored. Github releases is just a list. Updates on file based isnt needed for that small about of kB. The Updater just will download the newest html/css/js bundle zip
@mikeller just a small correction betaflight.tech is manged by me ;) blckmn has the control for betaflight.com. he also owns betaflight.tech but added it to my nameserver.
When needed i can host some autoupdate software under conf-update.betaflight.tech (or similar) but looks like nw autoupdate also works just with git
@wind0r but then how will nw.js be updated?
@McGiverGim: The problem is how often we can release a new version without user complaints. Back when we only had the Chrome Web Store version, we could release an updated version every month or so, and nobody ever complained. Now we have already had complaints about releasing too often...
@wind0r: Thanks for the correction. I meant more the server that both domains are pointing to at the moment, as a potential place to host files - what domain we use for the URL to refer to these files will be another question. :-)
This issue / pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.
Automatically closing as inactive.