We’re deciding which update technique to use for our plugin, and are trying to work out if it’s possible gracefully upgrade from an installed plugin (via rhi/macrhi) to a package manager version. For this, we have two goals:
I don’t have a plugin in this situation, but a few points:
I don’t understand the purpose of step 1.
Why not ship this update at a point when you know that you’re ready to switch to Package Manager and the update is sitting there waiting? Why do you need to build in the ability to look for exactly which version number update is available in Package Manager or hit a server at all to know this?
I would suggest breaking ID numbers (not sure what Mac uses?) so that the plugin looks like a new plugin to Rhino: it installs cleanly and doesn’t have any filename/path collisions.
Build the ability to remove the old version into the new version. That part might include some unloading of the existing one if Rhino supports it and if Mac views the file as free to delete at that point or some other mechanism like a little separate executable that the plugin starts while Rhino is running and waits until it closes, or that the user is instructed to run while Rhino isn’t running- whatever’s convenient.
Yes - that is the intention for the first version.
The reason for including a version check within the plugin is to be able to notify people when an update is available as this is for a web-connected service. Though @csykes has pointed out that this is easy enough - thanks!
I think that is good enough for the first part Checking for Updates
Good idea - I hadn’t considered that. The plugin in question also bundles a grasshopper plugin, so changing Ids could be painful (though perhaps only changing the Rhino plugin Id would be necessary).
And this is still somewhat problematic if the new version won’t load because the old one is still installed