Replies: 5 comments
-
|
Gerard, It might be possible to add an option to a plugin that would allow a user to be sent a message when an update is available - just a thought. Another possibility might be to include a redirect in the plugin repo that would allow the plugin to be installed from a different repo. I would need to look into that to see if it is even possible. As it is now the plugin installer (a plugin) uses information in the *.maifest file to fetch individual files from the github plugins repo and save them to the appropriate locations. It may be possible to use this to pull files from a different repo. It would require a modification of the plugin installer and manifest file to get the repo location to pull from. This seems doable. Dan |
Beta Was this translation helpful? Give feedback.
-
|
Notifying the user preferably on the hompage of updates on the core or plugins is a good idea. It must be configurable though because not all users want SIP to talk to the outside world continuously or don't have inet connectivity all the time. I'm thinking of adding an option to the plugin to update from a (or the) beta channel so the user can select from where to update. If time permits I will do some testing in the near future an let you know if something usable comes out of it. --Gerard |
Beta Was this translation helpful? Give feedback.
-
|
I just pushed a SIP update that allows plugins to show data/messages in the footer of the UI (shows on all pages) as well as in the timeline when a station is running. Enable the proto plugin to see it in action. The system updater plugin already can check for core updates and list the changes. It would be possible to extend that plugin to check for updates on a regular schedule such as once a month and show a notification if there are any updates. there could be a check box on the plugin's page to enable/disable the feature. What do you think. Dan |
Beta Was this translation helpful? Give feedback.
-
|
Footer looks nice and usable! My second thought would be, what about multiple plugins using the footer, will it still be readable? And how "costly" is starting a separate thread? The last might be no issue at all but sometimes I'm thinking in microcontrollers where every byte and cpu cycle counts. :-) Updating the plugins from the core updater is from the users pov the easiest. For us is might be a little challenge since you have to keep track of individual plugin versions to decide whether or not to update. Since all plugins are now in one repo the versioning should uniformely done in the plugin. For my own plugin I'm also searching for a reliable and maintainable way to do this. So far I haven't made a choice yet. For development and bugfixing directly to the enduser I still opt for adding the "beta release" option. Selecting the beta release channel then will point to another repo/branch from where the update of install can be done. At the moment for development I use a dev branch in my own Gitlab repo and do the deployment with Ansible. So only two commands needed (git push & ansible) to deploy a new version of the plugin. More testing, thinking and mostly learning has to be done. I will let you know how it goes. --Gerard |
Beta Was this translation helpful? Give feedback.
-
|
A simple first version of the self updating plugin is working now. If you don't laugh you may have a look here. I'm still have no satisfying solution for versioning the plugin. May be using the manifest file for it? |
Beta Was this translation helpful? Give feedback.
-
Hi Dan,
How are plugins currently updated? I briefly looked at your code but couldn't find it.
Also I'm thinking of adding a (advanced/beta) option to my plugin to update from a different repo. In this way I think end-users support can be done quickly without possibly breaking the main branch of the plugins . There are of course other options, e.g. select another branch or a complete other repo.
Do you have any ideas on this?
--Gerard
Beta Was this translation helpful? Give feedback.
All reactions