Fix for windows plug-in upgrades issue: #1623

[BaronGreenback]

Plugins are stored in version marked folders. (eg. TMDb Box Set.4.0.0.0) with only the latest version installed at start up.

The attempted removal of each earlier versioned folders can be enabled to be done at startup. (Disabled in this change) If the folder is found to be locked, another attempt can be made at the next execution of Jellyfin. At worst, the plugins folder may have some older versions left behind - which will be ignored by the system.

The system is backwards compatible - only "version loading" the folder if a version number is included in the folder name.

#1623

[BaronGreenback]

Is there a repository of older plugins which i could use for testing?

[crobibero]

Is there a repository of older plugins which i could use for testing?

https://repo.jellyfin.org/releases/plugin/

[dkanada]

@BaronGreenback a while ago Dolphin implemented a system to allow users to modify resource pack folders at will which I thought would be useful here. The plugin downloads would be inside a folder with a small file containing information like the GUID and version. This would allow any name for the files or folders as long as the metadata file is present, and would fall back to the existing behavior when missing. There would be some drawbacks to this method, but I figured I'd bring it up anyways for general discussion.

[BaronGreenback]

This versioning is basically to get around the issue of windows not being able to delete a locked file until reboot.

The package is already downloaded as a zip file - so any additional files could be included in that.
The JSON response from the plugin repository is the version number that routine uses for the folder creation - any internal versioning would have to match this one, or else run the risk of not being loaded.

What was the idea behind the metadata file? creating multi-plugin packages?

[BaronGreenback]

Have noticed that notification pops up saying (object object), so i don't know if i;ve introduced a bug. eg OpenSubtitles version ([object] [object])

[mark-monteiro]

I think you can get rid of a lot of the version parsing and comparison logic by using the Version class build into the framework: https://docs.microsoft.com/en-us/dotnet/api/system.version.parse?view=netcore-3.1#System_Version_Parse_System_String_

[EraYaN]

Nice, i like this a lot. We should probably store the manifest in the plugins zips (or generate it from the actual repo) and put it in manifest.json/yaml in the plugin folder. That way the name of the plugin folder is purely for informational purposes which seems more robust IMO, also lets you "disable" plugins by renaming the manifest or including a flag. And including the target server version too so a server upgrade can no longer break with a missing plugin or self heal by upgrading automatically.

[dkanada]

If we store a manifest in the ZIP it would increase the burden on third party repositories though.

[EraYaN]

If we store a manifest in the ZIP it would increase the burden on third party repositories though.

That is fair, but Kodi repos can also deal with it perfectly. We might need some "build" tooling. It does make it very easy to make a repo manifest from a folder of zips though. (we could even just package the build.yaml with a different name)

[EraYaN]

The plugin zips now have the meta.json files, so this should now be a solvable issue. Without depending on the actual path name, but discovery can just rely on enumerating all meta.json files in the tree.

[BaronGreenback]

@crobibero Named tuples implemented

[EraYaN]

Alright this seems that it might be ready for a merge, correct?

@jellyfin/core

[BaronGreenback]

yes - all the adaptations have been done that have been suggested.

[joshuaboniface]

Great solution! If we weren't so diverged already I'd mark this a stable backport, but I feel like that would be hopeless. So 10.7.0 🚀