|
Okay, I've spent a loooot of time with this problem and I believe I found a solution.
I tried to hand-craft a plugins.json.bz2 to see how Calibre behaves when encountering a deprecated plugin - but all the updater offered was to remove the deprecated plugin. It did not automatically offer to install the new one (which is what I hoped - a section in the plugin metadata that says "uninstall me and install replacement X"). That would be annoying as then everyone would need to manually download the new plugin either through a plugin search or from the new forum thread.
It looks like Calibre will auto-remove the old deprecated plugin when I install the new one, but it does not offer the user an auto-update from the old deprecated plugin to the new one.
So, I decided to implement a hack-y little trick to avoid A) having to make a new thread and B) having users have to re-install the renamed plugin:
- I've created a new build of my plugin that has the new name, a higher version number, and a bunch of install / migration code.
- I will attach that new build both to my plugin's thread, as well as to this thread I'm currently posting in.
- I will update (or rather, have a moderator update) the plugin index thread so that both the old and the new plugin are in there as non-deprecated plugins. The old one "DeACSM" will point to this thread, the new one "ACSM Input" will point to my plugin's thread. Of course the plugin description will be labelled accordingly so users don't get confused why this is there twice.
Then, the following steps should happen, if I tested this correctly:
- Calibre finds an update for the "DeACSM" plugin which gets downloaded from this thread.
- In this thread's ZIP, there's the new plugin that's actually already named "ACSM Input"
- Upon upgrading from the old installed version to this one, the plugin gets installed under the old "DeACSM.zip" name by Calibre (because that's what Calibre thinks it's installing).
- Then, it's initialization method copies the "DeACSM.zip" (which is now the new plugin) to "ACSM Input.zip" and restarts Calibre.
- At that point Calibre loads the new "ACSM Input" plugin from the ZIP file, and future updates will again come from the original thread of my plugin.
This has the disadvantage that I cannot yet label the "old" DeACSM plugin as deprecated in the plugin index (as then the migration to the new one would never happen; but it has the advantage of being completely seamless to the user, without him having to re-install the new plugin.
During my tests with a modified plugins.json.bz2 that worked just fine, so I hope it will work with the "official" one, too.
I hope that this is okay with the forum moderators, as it would mean my plugin would "occupy" two entries in the plugin list (neither of which can be in the "deprecated" section), and I would also need to "abuse" this particular thread to host my "migration build" of my plugin that moves everything from "DeACSM" to "ACSM Input"; but hey, this thread already exists anyways so that shouldn't be an issue - right?
|