Is there a buried lede here?
-
any DB access now goes through the core library
Out of curiosity, this is better because of encapsulation? Protection from bad plugins?
Basically, yes. Forces plugins not to use potentially database-engine-specific SQL so that server admins don't have to select their DB based on plugins for jellyfin being compatible.
-
I kinda agree here. https://jellyfin.org/docs/general/contributing/release-procedure/
Claims to follow semantic versioning, explicitly mentioning changes to plugin APIs as reasoning for a new major version.
Note however that the 10.Y.Z release chain represents the "cleanup" of the codebase, so it should be accepted that 10.Y.Z breaks all compatibility,
Its right there at the link you posted.
-
I kinda agree here. https://jellyfin.org/docs/general/contributing/release-procedure/
Claims to follow semantic versioning, explicitly mentioning changes to plugin APIs as reasoning for a new major version.
Their reasoning is literally the second sentence on that page.
Note however that the
10.Y.Zrelease chain represents the "cleanup" of the codebase, so it should be accepted that10.Y.Zbreaks all compatibility, at some point, with previous Emby-compatible interfaces, and may also break compatibility with previous10.Yreleases if required for later cleanup workAny 10.Y.Z release is cleanup and can include breaking changes. That's been the case for 10.9 and 10.10 already btw.
-
any DB access now goes through the core library
Out of curiosity, this is better because of encapsulation? Protection from bad plugins?
Also for internal use. The original emby source used not within the code base standardized database access.
Basically changes to the database were not possible since finding references across the code base which part uses which values was impossible.
-
I'm serious, there's so much lazy posting on Lemmy regarding software releases.
- no mention of what the software is or does
️ - no mention of what's interesting about the software or this release. ️
Jellyfin is quite a big name, but still, the pattern is clear.
I have to admit, it's something I'd like to see done a bit better (not that I'd be the one posting about it typically)
"Crocoslut version 12 released!"
Uh... great?
Though sometimes you go to the website and it's not much better.
- no mention of what the software is or does
-
I have to admit, it's something I'd like to see done a bit better (not that I'd be the one posting about it typically)
"Crocoslut version 12 released!"
Uh... great?
Though sometimes you go to the website and it's not much better.
Though sometimes you go to the website and it's not much better.
Dude yes. Among my comments you'll see that I ranted about this for a few days in the comments of another post. That's even worse, when you can't even find out for yourself.
-
Basically, yes. Forces plugins not to use potentially database-engine-specific SQL so that server admins don't have to select their DB based on plugins for jellyfin being compatible.
Brilliant.
-
Also for internal use. The original emby source used not within the code base standardized database access.
Basically changes to the database were not possible since finding references across the code base which part uses which values was impossible.
Ew. Yeah, good changes coming in that case. Glad they ironed that out!
-
Sorry, I didn’t realize some Lemmy clients don’t show cross-post descriptions. I’ll copy paste it below:
We are pleased to announce the first release candidate preview release of Jellyfin 10.11.0!
This is a preview release, intended for those interested in testing 10.11.0 before it's final public release. We welcome testers to help find as many bugs as we can before the final release.
As always, please ensure you stop your Jellyfin server and take a full backup before upgrading!
WIP release notes:
https://notes.jellyfin.org/v10.11.0_featuresThis is the first release that uses the new EF Core database mapper. If you'd like to help test this release, please remember to remove all plugins to make debugging logs as easy as possible.
My client showed that to me and I read it. I just imagined myself as someone who doesn't know what Jellyfin is, and that text didn't help much.
-
I have to admit, it's something I'd like to see done a bit better (not that I'd be the one posting about it typically)
"Crocoslut version 12 released!"
Uh... great?
Though sometimes you go to the website and it's not much better.
Crocoslut really started going downhill after the license change and conversion to nodejs in v9.
-
Crocoslut really started going downhill after the license change and conversion to nodejs in v9.
Crocoslut is yesterday. AlligatorAlly is the more friendly fork!
-
Their reasoning is literally the second sentence on that page.
Note however that the
10.Y.Zrelease chain represents the "cleanup" of the codebase, so it should be accepted that10.Y.Zbreaks all compatibility, at some point, with previous Emby-compatible interfaces, and may also break compatibility with previous10.Yreleases if required for later cleanup workAny 10.Y.Z release is cleanup and can include breaking changes. That's been the case for 10.9 and 10.10 already btw.
wrote last edited by [email protected]Sure they put a note in, but why not just follow semver to begin with instead of using semver with a bunch of asterisks, and essentially ignoring what semver is?
-
Sure they put a note in, but why not just follow semver to begin with instead of using semver with a bunch of asterisks, and essentially ignoring what semver is?
Consider the 10.y.z simply to be 0.y.z and everything works out.
Jellyfin inherited a lot of shitty code and architecture from emby. They simply cannot guarantee anything across patches until it is sorted out.
imho much better then releasing major version after major version because the break stuff regularly.
-
Note however that the 10.Y.Z release chain represents the "cleanup" of the codebase, so it should be accepted that 10.Y.Z breaks all compatibility,
Its right there at the link you posted.
"Breaks all compatibility [with emby]" was my interpretation of that. Not a huge deal either way but I'd definitely have been calling it 11 with this DB rework myself
-
"Breaks all compatibility [with emby]" was my interpretation of that. Not a huge deal either way but I'd definitely have been calling it 11 with this DB rework myself
... and may also break compatibility with previous 10.Y releases if required for later cleanup work.
If you read through the whole paragraph, it is clear that they mean the compatibility of previous jellyfin versions.
Also, again:
Note however that the 10.Y.Z release chain represents the "cleanup" of the codebase, so it should be accepted that 10.Y.Z breaks all compatibility,
That means that the code is not cleaned up with that release.
If you would release 11 before the code is considered cleaned up, you would basically break your own defined versioning convention. That is best decided by the active maintainers.
