Determine versioning policies

[joshuaboniface]

AFAICT there's no versioning in this repo, so it should closely track the main repo. Open to suggestions on how to accomplish this.

[EraYaN]

This repo should mirror the main repo's versions and tags. So we should make a release checklist, and follow that every release.

[hawken93]

I'd consider this and the jellyfin repo part of the same release, one even has to redirect to the deb files on the jellyfin repo on release

[joshuaboniface]

The release checklist is a very good idea. I agree that they should be the same "version" across both, so that any release stuff is consistent. I'm not sure however if there's a good way to automate that.

[hawken93]

Ansible it! :D

[EraYaN]

Well if python wasn't an okay build dep...

POSIX shell! (or bash now) ;)

Ansible seems almost overkill

[hawken93]

I'm not sure ansible would really be all that good at it. anyway, it looks a bit like:

• do merge in jellyfin-web
• do the usual release stuff in jellyfin (merge there)
  • also make sure it points at jellyfin-web's merge
• tag both
• make release in jellyfin

I think that's mostly it sorry about the heavy editing

[joshuaboniface]

Actually, we can make use of Org-level projects to help with this, but it doesn't directly help with versioning per se:

https://github.com/orgs/jellyfin/projects

We could make release projects there, include issues/PRs from the multiple relevant repos (jellyfin, jellyfin-web, and any submodules), and go from there.

I noticed that most of the PRs in this repo are against Master, so we should stop doing that ASAP and do them against dev, so we can follow the same procedure in both repositories. A master release PR would then happen in both at the same time, tracked in the same project.

cc @anthonylavado as our resident project master.

[dkanada]

I actually think they shouldn't stay locked together, since the eventual goal is to be able to host the frontend separately if you want. The web frontend is already pretty close and we will need some backend changes to not serve the frontend at all with a toggle setting. The same argument that people were using for other clients (what if the frontend gets a major redesign or rewrite to Vue or React that modifies behavior and should get a major version bump but the server hasn't had enough changes) still stands for this repository.

[joshuaboniface]

@dkanada I agree with you one we reach full separation, but for the near future they should closely track each other as much as possible, given how tightly integrated they are. That's something none of the other apps need to really deal with.

I'm hoping that the full separation can happen for 10.1.0, i.e that 10.1.0 would have a "Server" package and a "Web" package, with the server part being able to run without the WebUI installed, and the WebUI can (somehow) communicate with the server. I'm not sure exactly how this will work though - this needs thorough input from as many people as possible. CC @jellyfin/core @Bond-009

This means we'd really just be doing bugfix 10.0.X releases for the next little while based off cherry-picked PRs, rather than major features, until this is ready. I'd like for us to, if at all possible, prioritize this separation to avoid them being tightly coupled for too long, but we can reevaluate after a week or so where we're at for 10.0.2 and go from there.

[EraYaN]

On that separation. I'll give it a go this weekend. I like ASP.NET and have done some work on it already so, that as a base HTTP server should be fine. How do we feel about multiple ports?

[JustAMan]

How do we feel about multiple ports? I personally feel against, it complicates reverse-proxying a bit. But if making it is way easier this is up to discussion.

As for versioning - I think that up to at least 10.1.x we should treat two repos with same version. I support the position that we should start versioning them separately when they're really fully separate.

[ViXXoR]

On that separation. I'll give it a go this weekend. I like ASP.NET and have done some work on it already so, that as a base HTTP server should be fine. How do we feel about multiple ports?

Does this mean running Kestrel as the web server? If so I like it.

As for multiple ports, I'm also not a fan. Just my 2 cents.

[EraYaN]

Kestel yes, non multiple ports does mean that kestrel will have to proxy all API requests and websocket connections. Well then at least is can handle full https termination.

[JustAMan]

I too want one port (with potential http or https choice, but probably not both). Plus a configurable url prefix (not a hardcoded /emby as it is now).

What are benefits of having multiple ports btw?

[EraYaN]

Well that clients can directly talk to the API endpoint, since if these are two machines, proxying it from one device to the other incurs latency. And then your web server also needs to pass all media traffic. But alas, https is more important.

[JustAMan]

In this case we can have a "know-it-all" port for capturing all requests and "API-only" port that works via nginx/apache/whatever...

[ViXXoR]

Would we still have the option of having a Docker build or something that would be an all-in-one setup? I know personally I would prefer to just run a container or service and be done with it, no reverse-proxy or web server setup, if possible.

[JustAMan]

One can always package nginx inside the docker image, that is probably the easiest place.

[joshuaboniface]

Yup and the split .deb/.RPM files could depend on one of nginx/apache2/etc.

[EraYaN]

You would have a meta package jellyfin-server that depends on jellyfin-server-core jellyfin-server-web or something like that. I think we would still use Kestrel as the default even in those packages. Since well, it is much easier than dealing with the hundreds of slightly different ngnix/apache config setups between all the different distros and versions. That is something for admins to do by themselves.

[hawken93]

my 2 cents are that installing 2 packages and having jellyfin serve the frontend too would be a good default setting to keep it simple, since this split mostly serves power users anyway that seek to scale it up. I would want that both user bases are happy about this. Ideally outside of docker too.

If I wanted to split them up, I would toggle the setting so the server doesn't serve up the frontend and I would point a webserver to the web files either locally or by installing them elsewhere :) I see this all as possible in @EraYaN s explanation and I support it :)

[dkanada]

@joshuaboniface would you say this can be closed for now? We will be tracking the server releases for the near future.

[joshuaboniface]

Yea I think so, how we have it is working well for now. Can revisit with webng.