Reduces number of requests done against (rate limited) github API, especially after consecutive server restarts. Forcing the update check still will query the API.
That's also able to cope with 0.3a and similar "non-semantic" version schemes. Semantic version comparison can still be forced by setting the compare_type in the check to "semantic". Strict equality check can be set similarly by using the value "unequal".
That's more user friendly than just blindly reloading the page. Also include installed Template- and AssetPlugins in the check whether there's a new version or not.
Caused by a wrong variable usage. Fixed the usage and added a migration
step that fixes the circular reference if it exists. Bumping configuration
version to 2.
Fixes#946
Introduced new callback for settings plugin to hook into the point after the settings have been migrated since the initialize method is not suitable for that as it might be called before other plugin implementations reachable through hooks are initialized.
Usage of super(MyClass, self) is henceforth discouraged due to dynamic reloading within OctoPrint's plugin subsystem. Refer to https://thingspython.wordpress.com/2010/09/27/another-super-wrinkle-raising-typeerror/ for details on this problem.
Action by plugin authors is needed to remove the super(...) call and substitute it with octoprint.plugin.SettingsPlugin.on_settings_save(self, data) and octoprint.plugin.SettingsPlugin.on_settings_load(self). Without these modifications, calls to plugin methods utilizing super(...) will fail after a call to the plugin managers reload_plugins method.
Closes#942
The SoftwareUpdate Plugin had a bug that caused way too much check data to be stored in the configuration, leading to plugins potentially being stuck in an "update available" loop although the update had already been applied. Now only the current version of github_commit update types is persisted, not the full check configuration.
Also introduced a configuration version and made the migration function migrate old configs to remove anything that was same as the default supplied for the "octoprint" and all plugin hook checks. That should clean things up in existing installations.
OctoPrint will take care of calling a migration function on the plugin if the plugin demands a newer configuration version than currently stored in config.yaml.
When any plugins are enabled/disabled, the client now gets a trigger to fetch a fresh list of update information from the server. This should take care of any old popups still hinting at now uninstalled plugins.
This is to make sure that they all end on a ; and hence stuff doesn't break if a file included directly after starts with a (...) construct. Of course it would be better if all bundled files are valid in that matter, however since we can't enforce that, we'll add this slight overhead to reduce the risk of stuff breaking.
See for example: http://stackoverflow.com/questions/20307462/js-cant-combine-lib-files
python-setuptools on OctoPi is quite old and trying to update in a local virtualenv apparently CAN cause problems (we had this with python-serial too a while back), so a backwards compatible solution is better here.
If plugins get enabled or disabled, the update check configuration needs to be refetched next time it's needed since there might have been changes to plugin implementing the check_info hook.
