Handle incompatible plugins from major upgrade

[jjw24]

@Flow-Launcher/team thinking of how to handle incompatible plugins after a major upgrade. This is brought about by 1.8.0, but we would likely hit this again in the near future. This is for situations where it is not feasible to provide backwards compatibility, i.e. Everything plugin.

When a plugin is incompatible, I think we can do:

1. mark the plugins in the code that will be incompatible, this is for the dev making the major upgrade to do.
2. either provide a new plugin version release that these incompatible plugins have,
3. or disable these plugins
4. if a plugin has a new compatible version release then download, extract the new plugin and make it ready for use

[pc223]

To further safe guard againts future bugs 🐛 and incompatibility, I think Flow should tell users where to get help when errors happen in general 😄

Like, "BOOM! Error: ExceptionBlaBlaBla: Please go to ... to get help".

Maybe with some contact info like:

• Github issues
• Discord
• Maintainer email?
• Project email? (googlegroups? - Normal users tend to prefer emails more than Github 🤔)

Maybe some kind of instructions to get logs file/write bug report.

If possible, some kind of auto-capture context data, to help with postmortem debugging. I'm pretty sure C# has some kind of debugging tools like that. (serilog?)

[taooceros]

To further safe guard againts future bugs 🐛 and incompatibility, I think Flow should tell users where to get help when errors happen in general 😄

Like, "BOOM! Error: ExceptionBlaBlaBla: Please go to ... to get help".

Maybe with some contact info like:

• Github issues
• Discord
• Maintainer email?
• Project email? (googlegroups? - Normal users tend to prefer emails more than Github 🤔)

Maybe some kind of instructions to get logs file/write bug report.

If possible, some kind of auto-capture context data, to help with postmortem debugging. I'm pretty sure C# has some kind of debugging tools like that. (serilog?)

Flow already have that if a outside bug is triggered. However, the current build will only trigger that if exception other than plugins exception is thrown. #470 is trying to make that perform better.

[taooceros]

Project email? (googlegroups? - Normal users tend to prefer emails more than Github 🤔)

Regarding this, there's an interesting project doing this. https://fire.fundersclub.com/#SetUp

[taooceros]

A few thought

1. PluginsManager need to be changed to detect the latest supported plugin version for a specific Flow version
2. Plugin developer will also need to mention supported Flow version (probably in plugin.json?).
3. PluginsManifest need to be changed to include more release version and the supported version information. Probably, users may be allowed to choose which version to download.
4. I don't think these information should be included in Flow like this commit except for the current everything plugin. They should be included in Plugins' repo.

[jjw24]

Project email? (googlegroups? - Normal users tend to prefer emails more than Github 🤔)

Regarding this, there's an interesting project doing this. https://fire.fundersclub.com/#SetUp

this is good, we should set up this

[jjw24]

A few thought

1. PluginsManager need to be changed to detect the latest supported plugin version for a specific Flow version
2. Plugin developer will also need to mention supported Flow version (probably in plugin.json?).
3. PluginsManifest need to be changed to include more release version and the supported version information. Probably, users may be allowed to choose which version to download.

is 1-3 to solve downloading latest plugins that old version of flow does not support?

[jjw24]

Alternative we can actually add backwards compatibility by re-adding the old methods and classes and updating the new class+ methods to a different name: #481

Technicality wise, what do you think? @taooceros

[pc223]

Project email? (googlegroups? - Normal users tend to prefer emails more than Github 🤔)

Regarding this, there's an interesting project doing this. https://fire.fundersclub.com/#SetUp

this is good, we should set up this

Should tell plugin-dev to provide email too. Maybe put the email field in plugin.json? (make sure they aware that this email is going to be public ⚠️ )

I surprise that Github doesn't have built-in support for email 😮

Alternative we can actually add backwards compatibility by re-adding the old methods and classes and updating the new class+ methods to a different name: #481

Technicality wise, what do you think? @taooceros

I prefer this approach, But, have to make plugin-dev knows that they using old API, and Flow will end support for that API in the future, so that plugin-dev knows to upgrade to the new API.

I prefer a Msgbox warning ⚠️ when Flow runs, so that even normal-users aware of the plugin is using an old API, maybe users should consider using alternative plugins. (Kind of pressure plugin-dev to update 😅 )

And a lot of the time, plugin-dev is normal-users too => don't read the new Flow-docs => don't aware of changes of API => Flow have to force them a bit 😅

[taooceros]

Alternative we can actually add backwards compatibility by re-adding the old methods and classes and updating the new class+ methods to a different name: #481

Technicality wise, what do you think? @taooceros

I think currently no old methods is removed, so no other plugins are currently incompatible (at least those plugin in my computer). Everything plugin is not compatible because of the reference to Old_Infrasturature.dll.

[taooceros]

I surprise that Github doesn't have built-in support for email 😮

I guess they do this because they would like people to at least register an account. Github do allows people to respond issue with email.

I prefer this approach, But, have to make plugin-dev knows that they using old API, and Flow will end support for that API in the future, so that plugin-dev knows to upgrade to the new API.

I prefer a Msgbox warning ⚠️ when Flow runs, so that even normal-users aware of the plugin is using an old API, maybe users should consider using alternative plugins. (Kind of pressure plugin-dev to update 😅 )

And a lot of the time, plugin-dev is normal-users too => don't read the new Flow-docs => don't aware of changes of API => Flow have to force them a bit 😅

Good idea

[taooceros]

is 1-3 to solve downloading latest plugins that old version of flow does not support?

Is for downloading latest plugins that old version of flow does support (it would be more possible that a version of plugin is not supported by older version of flow comparing to a newer version of flow).

[jjw24]

This pr will not go ahead. New changes are in #481, which adds backwards compatibility via restoring previous class and interface used by Everything plugin.