Plugins 2.0 - Electric Boogaloo


Alright - in our next version, 10.3.0, we will be in the second release of JF that officially supports its own plugins.

We need to discuss and settle the following:

  • How many versions of JF do we support?
  • What fields can we use in the manifest to enforce an exact server version?
  • Are there any changes that we want to make to the manifest format?
  • How should plug-ins continue their versioning?

Out-of-order, since I address them in an order relevant to my idea here.


Well there’s a lot of duplication and superflous stuff in there, but the options we need to do versioning should remain of course, and some of the duplication removed. I think the general format and idea of the manifest works well.

Fields / Versions to support

From my understanding, based on this snippit:

        "versions": [
                "checksum": "c3188fc501faffd841d8fb422f029699",
                "classification": "Release",
                "description": "Release",
                "name": "Anime",
                "packageId": 0,
                "requiredVersionStr": "10.1.0",
                "runtimes": "netframework,netcore",
                "sourceUrl": "",
                "targetFilename": "",
                "timestamp": "2019-03-11 21:29:55",
                "versionStr": "1.0.0"

Now first, there’s something about this I’m no clear about, because I’ve never actually used any Emby/Jellyfin plugins: was the intent of versions being in an array to support multiple plugin versions, or multiple server versions? If the former, that’s weird but OK not out of character. If it’s the latter though, and I think it would work that way even if it was the former intent, then we have options.

We’d just need to set two entires, one built with e.g. 10.2.0, one built with 10.3.0, then set the requiredVersionStr and sourceUrl to be different for each, while keeping targetFilename the same. Basically keep the “old” one around and just add the new one each release.

New versioning

Most of them have been set to 1.0.0, but I’d suggest we do a Google-style versioning going forward: start at 1, and increment based on changes. Each PR bumps it (in build.yaml) by 1 (so from 1, to 2, to 3, etc. no subversions), and make that part of the PR requirements. This would work out well in conjunction with the Fields, so we’d have as I understand it:

  1. Release version e.g. 5 of plug anime. Current server release is 10.3.0. Build containing anime_5.dll and add this to the versions array.
  2. New release of the server happens. Build a new version of anime against the new ABI targets (via Nuget?), append it into the manifest with containing anime_5.dll. Based on how this should/seems (testing required) to work, this will let 10.3.0 users continue to DL the old one, then 10.4.0 users download the new one, and I suspect newer-first order would matter.
  3. Mid-release, we make a PR in Anime, and get version e.g. 6. This is where we have some complexity:
    a) We rebuild 6 against all the previous ABI versions we support (maybe 3-4, or the last two stable, or something), and release a new set of DLLs. This ties back into a though further back - I don’t see much point at all of having available multiple versions of the plugin at any given time, so we’d update the entire manifest from anime_5 to anime_6.
    b) We only release the new plugin version for the current stable, and then keep rolling forward like that. I’m less of a fan of this option, but it would “let” us preserve old versions of the plugins in the manifest while keeping the more recent one up-to-date. I don’t like the idea of rebuilding old plugin versions against new ABIs, but maybe there’s a good reason to? IDK

Really both of these could be implemented fairly easily inside the build.yaml infra I have set up for building plugins, assuming there’s an easy way to control NuGet dep versions dynamically at build time.


Most of the code change to make this work is in #1188 and implementing the plugin side is pretty easy. Experimenting with Anime and Trakt first since they’re easy to understand and modify.

Implementing the JSON stuff should be straightforward as well, will give that a shot.

1 Like