point pluginsmanifest to new api branch #548
Conversation
|
@taooceros @JohnTheGr8 as per discussion, good to go? |
Have you checked what @Zeroto521 says? |
|
Just saw it, ok let me think about this |
|
Has anyone tried to see what happens when Flow updates but a previously installed plugin is no longer compatible? Does new flow simply ignore it (not load it)? |
|
what scenario you are talking about ? i have tested dev branch's build with all plugins we currently have, they are all compatible |
I think Flow will pop out a message saying that a specific plugin is unable to load, and disable it. |
Yeah, if the plugin fails to load, that message will pop up. If flow is .net core and plugin is .net 5, the same message will pop up |
That's what I meant. Maybe we should be auto-updating these if possible? Or prompting the user to update it (assuming an update is available) |
|
We can't do anything for users on 1.7.2 or earlier, any changes will be 1.8.0 onwards. This scenario is not valid anyway because with the branch system, they won't be able to download unsupported plugins |
What I mean is: if a plugin is installed under Flow 1.7.2 that is not compatible with 1.8.0 because of a breaking change, and the user updates their Flow to 1.8.0, the plugin will still be there in the AppData folder.... If this happens and the plugin fails to load, it would be nice to prompt the user to simply update the plugin to a version that is compatible. |
|
After the fix for everything plugin, I don't believe we have introduced some breaking change for plugin systems in 1.8.0. But that's an interesting idea. |
I don't think this is a necessity for 1.8.0 release, we have tested the current plugins. This logic is a bit hard to achieve though, if we can figure out the plugin failure to load is due to lower version plugin, we need to check if a newer version is available. What if plugin load failure is because the plugin tried to write data to a protected folder? May be a lot faster to just help user read the error logs than to write up logic to determine the type of failure? |
|
@taooceros @JohnTheGr8 can we get this moving along and merged? |
Testing all the plugins for every big release cannot be fun, that's all... ;) But yeah, I think this is good to go. |
Agree, not fun haha. Let's work on your suggestion for the next release after 1.8.0 |
use the new branch in PluginsManifest per discussion