Plugin versioning


#1

Now that we’ve opened up for some plugin dev/support, maybe we should discuss versioning? Eg. Trakt is currently 3.2.2.0. The ported version should bump it to what?


#2

My opinion:
They should match the major of the Server Core, but after that it’s fair game.

This way, if we’re following SemVer for the server, we know that version 11.Y.Z has major API changes, and thus the user should have a matching 11.B.C plug-in.


#3

I know that automated ABI checks are being worked on, but just fyi, plugins built for 10.0.x do not work with 10.x.y.


#4

Right - we’ve made a bunch of changes in that regard. I’m not so sure then. @joshuaboniface?


#5

Does it make sense to tie ABI versioning to API versioning? Seems like this would require major version bumps for breaking changes on either of them, unnecessarily breaking compatibility for the other.


#6

I’m not too sure, do we know what actually broke them? I’m still of the mind that the entire 10.Y.Z train is a “beta”, and stuff may break regularly until we stabilize, at which point we’d release 11.Y.Z which would be the first real “stable” release without frequent backend breaking changes.


#7

I suppose since there were changes that required a new re-pack of our NuGet stuff, which is:

  • Jellyfin.Common (available from 10.0.0, now in 10.1.0)
  • Jellyfin.Model (as above)
  • Jellyfin.Controller (as above)
  • Jellyfin.Naming (new for 10.1.0)

@Leo_Verto - I was just thinking about how to avoid “3.5.3 works on 10.1.0”, but I suppose once we give people a plugin catalog, it shouldn’t really matter much.

We’ll just need to have a way to identify what release versions each plug-in supports.