Author Topic: Plugin Update Notification/Updater  (Read 23041 times)

derTyp

  • Jr. Member
  • **
  • Posts: 71
Hi,

it would be nice if MusicBee would be able to notify you about available Plugin updates.
 
As the Plugin metadata is currently hosted on the website it should be possible to integrate this with a relatively simple API, maybe even do some verification of the data. If there is an update a popup could be shown that guides you to the new download, etc.
Even better would be an automatic update (opt-in) but this would require a common format of distribution for plugins and could be hard to implement.

I see that the version with the most downloads is, most of the time, the first version released (at least for my plugins) and i think this could really help to get new features to all users of a plugin.

This has already been requested here, but at that time I think there was no official Hub for plugins as it is now.

Best regards,

boroda

  • Sr. Member
  • ****
  • Posts: 4679
+100500. and it would be useful if dashboard for add-ons supports 'last updated' tag along with 'version'.


AvikB

  • Sr. Member
  • ****
  • Posts: 945
+100500. and it would be useful if dashboard for add-ons supports 'last updated' tag along with 'version'.
"last updated" is already supported. it is not user editable. The system automatically sets the last updated date.


AvikB

  • Sr. Member
  • ****
  • Posts: 945
I agree there should be an auto updater for addons. but there are few challenges. Even though the data is stored in the database. The downloads are hosted in 3rd party website so no auto download feature.

There is already API available for the website to access the addon info stored in the website:
https://getmusicbee.com/help/api/

you will need the addon id to get the data though. but right now there is no way to detect what addons are installed and what their id, version is. Add-on devs need to include the id and the version ... maybe in a XML file. then musicbee can read that XML file for each addons that are installed and then check for the update using the API.

but i have seen a lots of the time add-on devs not using the "version" field properly or increment them after each update. My initial goal is to make a updater plugin eventually.  :-\
but the only problem is that It will require extra work from addon devs. If the add-on devs are willing to do this i can make a plugin for the musicbee that will notify if a newer version is available or not.


boroda

  • Sr. Member
  • ****
  • Posts: 4679
but the only problem is that It will require extra work from addon devs. If the add-on devs are willing to do this i can make a plugin for the musicbee that will notify if a newer version is available or not.
this would be great. just foresee that some add-on devs wont support update notifications. such add-ons (eg. without proper manifest/xml/etc.) must be marked in add-on updater somehow.

derTyp

  • Jr. Member
  • **
  • Posts: 71
To get this going I don't think we should talk about auto-upgrades first. This has so much implications like packaging format, support for old versions, security, hosting services, etc. As a first step it would be nice to get a notification for users if there is an update available.

In my opinion it would be better to have this functionality in the core MusicBee program. Given the importance of such a plugin, everyone should get this functionality out of the box.

On the other hand I would like something, that basically all add-ons should use, to be open source. So maybe it would be possible to develop an updater plugin in a github repo and get it preinstalled with every new release of MusicBee like the last.fm plugin or theatermode. I think this would be the optimal solution.
Ideally there would be a possibility(API function) to get the PluginInfo instance of all installed plugins. This class has most of the information needed (version, name, supported api) and every Plugin already uses it. Maybe Steven can add an AddonID field for the ID on the website to the class.

but i have seen a lots of the time add-on devs not using the "version" field properly or increment them after each update. My initial goal is to make a updater plugin eventually.  :-\
but the only problem is that It will require extra work from addon devs.
I don't see this as a problem, because if you care about your addon and want updates to reach your users, you can add/update a few strings. If not, you/your addon simply won't profit from update notifications/auto-update.
Also there could be workarounds for already installed addons or addons of which the id can not be determined, e.g. doing a search for the name on the website, asking the user which of these addons it is and saving the mapping in an internal DB.

boroda

  • Sr. Member
  • ****
  • Posts: 4679
derTyp, +1, but its very complicated things. we should start with something that is easy to implement (and we can evolve updater later). but i completely agree that add-on updater must be integrated in mb (not just as a plugin, even integrated plugin).

boroda

  • Sr. Member
  • ****
  • Posts: 4679
+100500. and it would be useful if dashboard for add-ons supports 'last updated' tag along with 'version'.
"last updated" is already supported. it is not user editable. The system automatically sets the last updated date.


i frequently update some plugin page (eg plugin description) without updating download link. will site change 'last updated' tag in this case?

AvikB

  • Sr. Member
  • ****
  • Posts: 945

 i frequently update some plugin page (eg plugin description) without updating download link. will site change 'last updated' tag in this case?
Yes, it should. The "last updated" field does not rely on changing the download link.

AvikB

  • Sr. Member
  • ****
  • Posts: 945
To get this going I don't think we should talk about auto-upgrades first. This has so much implications like packaging format, support for old versions, security, hosting services, etc. As a first step it would be nice to get a notification for users if there is an update available.
 

Yeah good idea. I think we need to establish a standard way to store the addon data that can be readable by the updater. I am thinking of XML file that stores the important data, maybe something like this:

Code
<?xml version="1.0" encoding="UTF-8"?>
<addon-data>
<name>Addon anme goes here</name>
<id>addon id according to the website dashboard</id>
<version>1.0.1</version>
</addon-data>

if needed we can add more field in future.

Also the .xml file naming scheme should be something like
Code
addon_*.xml

then the updater plugin can search through the directory and looks through all the files by that naming scheme and checks if a new version available or not. It shouldn't be too hard.


In my opinion it would be better to have this functionality in the core MusicBee program. Given the importance of such a plugin, everyone should get this functionality out of the box. On the other hand I would like something, that basically all add-ons should use, to be open source. So maybe it would be possible to develop an updater plugin in a github repo and get it preinstalled with every new release of MusicBee like the last.fm plugin or theatermode. I think this would be the optimal solution.

that could work. ofc we need to build it first and let Steven decide what to do with it.



Ideally there would be a possibility(API function) to get the PluginInfo instance of all installed plugins. This class has most of the information needed (version, name, supported api) and every Plugin already uses it. Maybe Steven can add an AddonID field for the ID on the website to the class.
That would be the ideal solution. In this case we wouldn't need the .xml file and reduce clutter. on the other hand all of the plugins need to adapt to these changes.




 
but i have seen a lots of the time add-on devs not using the "version" field properly or increment them after each update. My initial goal is to make a updater plugin eventually. :-\ but the only problem is that It will require extra work from addon devs.
I don't see this as a problem, because if you care about your addon and want updates to reach your users, you can add/update a few strings. If not, you/your addon simply won't profit from update notifications/auto-update. Also there could be workarounds for already installed addons or addons of which the id can not be determined, e.g. doing a search for the name on the website, asking the user which of these addons it is and saving the mapping in an internal DB.

I am against the search, it is not reliable for this sort of task. also it is quite heavy on the database.

Well we need to first decide how we want to implement it. I will update the website addon dashboard to show the ID after we decide the implementation.

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34408
I am happy to put something in MB. At the moment MB caches the plugin name and the plugin.dll name. I dont see a id working as a matching criteria unless some changes were made to the plugin "about" information block, but i dont think i want to do that due to breaking existing old plugins.

@AvikB, so would the xml block you describe be available similar to: https://getmusicbee.com/rss/ ?
I would suggest including the update date/time in UTC format as well in case the plugin developer forgets to increment the version info

boroda

  • Sr. Member
  • ****
  • Posts: 4679
for PluginInfo: i think we must support all kinds of add-ons, eg. skins. so i think xml manifest is better solution even if its harder for devs.

@AvikB:
if you write example update notifier plugin to integrate it into mb later, write it in visualbasic as mb is written in vb.

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34408
maybe i have misunderstood what is being proposed, but i had understood that when a plugin (or skin) is updated on the addons page, that the update would get included in a queryable xml block, similar to https://getmusicbee.com/rss/
if thats the case, i am happy to have MB query that xml data and for anything matching the user's installation and alert them.