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:
"timestamp": "2019-03-11 21:29:55",
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
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.
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:
- Release version e.g. 5 of plug
anime. Current server release is 10.3.0. Build
anime_5.dll and add this to the
- 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
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.
- 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
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.