Show improved version information to users #285

New Issue

OVERLORD · 2026-02-06T19:32:48+03:00

OVERLORD commented

2026-02-06 19:32:48 +03:00

Originally created by @joshuaboniface on GitHub (Jan 16, 2019).

A spin-off discussion from #508 and #509.

Let's discuss our opinions and philosophical arguments for various forms of improved user versioning information.

Originally created by @joshuaboniface on GitHub (Jan 16, 2019). A spin-off discussion from #508 and #509. Let's discuss our opinions and philosophical arguments for various forms of improved user versioning information.

OVERLORD added the roadmap enhancement labels 2026-02-06 19:32:48 +03:00

OVERLORD closed this issue

2026-02-06 19:32:49 +03:00

OVERLORD commented

2026-02-06 19:32:51 +03:00

@joshuaboniface commented on GitHub (Jan 17, 2019):

What I'd like to see

A numerical version string that is consistent with our release versions.
On dev builds, a commit hash of where the repo was at build-time. Not just the main repo, but the jellyfin-web repo as well.

Why?

Users need to see the version quickly but not be confused by additional information.
Developers need to be able to quickly troubleshoot where they are on each dev build in order to work consistently off each other.

@joshuaboniface commented on GitHub (Jan 17, 2019): # What I'd like to see 1. A numerical version string that is consistent with our release versions. 1. On dev builds, a commit hash of where the repo was at build-time. Not just the main repo, but the `jellyfin-web` repo as well. # Why? 1. Users need to see the version quickly but not be confused by additional information. 2. Developers need to be able to quickly troubleshoot where they are on each dev build in order to work consistently off each other.

OVERLORD commented

2026-02-06 19:32:52 +03:00

@EraYaN commented on GitHub (Jan 17, 2019):

I can modify the #508 to contain those pieces of info. But that won't reduce it's complexity in anyway. You will still need a script, a file and something to parse it. We can debate for a long time about what the least complex file format is, but frankly it really doesn't matter. For all I care it's fucking json if that makes anyone happy.

Long story short, we will end up if we want the above points at the same level of complexity regardless. All the other points are implementation details, and are frankly a lot more inconsequential.

@EraYaN commented on GitHub (Jan 17, 2019): I can modify the #508 to contain those pieces of info. But that won't reduce it's complexity in anyway. You will still need a script, a file and something to parse it. We can debate for a long time about what the least complex file format is, but frankly it really doesn't matter. For all I care it's fucking json if that makes anyone happy. Long story short, we will end up if we want the above points at the same level of complexity regardless. All the other points are implementation details, and are frankly a lot more inconsequential.

OVERLORD commented

2026-02-06 19:32:53 +03:00

@ploughpuff commented on GitHub (Jan 17, 2019):

@joshuaboniface I have put together a 'help' page for devs when running from command line:
61eb8a9e3c

Worth pursuing with?

@ploughpuff commented on GitHub (Jan 17, 2019): @joshuaboniface I have put together a 'help' page for devs when running from command line: https://github.com/ploughpuff/jellyfin/commit/61eb8a9e3c4edc3dc513cb7755c5c2affcd2d827 Worth pursuing with?

OVERLORD commented

2026-02-06 19:32:54 +03:00

@JustAMan commented on GitHub (Jan 17, 2019):

Great find by @anthonylavado: https://github.com/AArnott/Nerdbank.GitVersioning

@JustAMan commented on GitHub (Jan 17, 2019): Great find by @anthonylavado: https://github.com/AArnott/Nerdbank.GitVersioning

OVERLORD commented

2026-02-06 19:32:54 +03:00

@joshuaboniface commented on GitHub (Jan 17, 2019):

@EraYaN @nvllsvm @Bond-009 This GitVersioning thing looks to be literally exactly what we want. Is it feasible to use?

@joshuaboniface commented on GitHub (Jan 17, 2019): @EraYaN @nvllsvm @Bond-009 This GitVersioning thing looks to be literally exactly what we want. Is it feasible to use?

OVERLORD commented

2026-02-06 19:32:55 +03:00

@EraYaN commented on GitHub (Jan 17, 2019):

Well it will only stamp the current git version of one repo, AND it will not use a three part semver but only a 2 part semver. If you can live with that concession, I guess yes.

It also needs the .git folder during build at all times.

@EraYaN commented on GitHub (Jan 17, 2019): Well it will only stamp the current git version of one repo, AND it will not use a three part semver but only a 2 part semver. If you can live with that concession, I guess yes. It also needs the .git folder during build at all times.

OVERLORD referenced this issue

2026-02-07 05:40:24 +03:00

[PR #285] [MERGED] Use Serilog to handle logging #8240

OVERLORD referenced this issue

2026-02-07 05:41:45 +03:00

[PR #419] [MERGED] Master 10.0.0 #8310

Sign in to join this conversation.