cross-posted from: https://aussie.zone/post/19146681
Important Notes
Configurations behind a reverse proxy that did not explicitly configure trusted proxies will not work after this release. This was never a supported configuration, so please ensure you correct your configuration before upgrading. See the updated docs here for more information.
Security
- Fix validation of API parameters to FFmpeg [GHSA-2c3c-r7gp-q32m], by @Shadowghost
- Fix trusting forward headers if none are configured [GHSA-qcmf-gmhm-rfv9], by @JPVenson
Note: GHSAs will be published seven (7) days after this release.
General Changes
- Fix regression where "Search for missing metadata" not handling cast having multiple roles [PR #13720], by @Lampan-git
- Clone fallback audio tags instead of use ATL.Track.set [PR #13694], by @gnattu
- Backport 10.11 API enum changes [PR #13835], by @nielsvanvelzen
- Support more rating formats [PR #13639], by @IDisposable
- Fix stackoverflow in MediaSourceCount [PR #12907], by @JPVenson
- Upgrade LrcParser to 2025.228.1 [PR #13659], by @congerh
- Include Role and SortOrder in MergePeople to fix "Search for missing metadata" [PR #13618], by @Lampan-git
- Delete children from cache on parent delete [PR #13601], by @Bond-009
- Fix overwrite of PremierDate with a year-only value [PR #13598], by @IDisposable
- Wait for ffmpeg to exit on Windows before we try deleting the concat file [PR #13593], by @Bond-009
- Fix 4K filtering when grouping movies into collections [PR #13594], by @theguymadmax
- Remove empty ParentIndexNumber workaround [PR #13611], by @Shadowghost
- Update dependency z440.atl.core to 6.20.0 [PR #13845], by @Shadowghost
General Changes
- Fix parsing minor version of Tizen [PR #6661], by @dmitrylyzo
- Fix re-focusing on pause button when displaying OSD [PR #6510], by @dmitrylyzo
- Fix skip button not displaying correctly with OSD [PR #6583], by @rlauuzo
- Fix catalog plugin page not setting page title [PR #6570], by @nielsvanvelzen
It's odd to throw that into a patch release. I guess we'll find out if I did it correctly.
I mean, it's patching a security issue caused by trusting headers it shouldn't, so I don't think they should wait for a big number release.
Why wait? Just release it as a big number release. The version number doesn't define the size or cadence of a release, it just says whether there's a breaking change.
At least in my org we use semantic versioning ( Major.Minor.patch) where patch must either be a new feature, a fix, or something that is backwards compatible
Minor can be breaking
Major is basically something you're proud of lol
That's not semantic versioning...
Guess my org fucked it up ¯\(ツ)/¯
I mean, where else should they show that warning? It's also posted in the forum. They also edited the documentation page.
Maybe you're more into mailing list or the like? I'm genuine curious on what/ how/ where you expected getting this kind of information.
I expect in a patch release that nothing has changed and I can blindly update getting minor bug fixes and security fixes. In a minor release I expect to review the changes for configuration changes or any minor UI changes. For a major release I expect to read docs on how to upgrade and prepare backups and downtime.
Exactly. It has nothing to do with where they post it, but what their version numbers communicate. I should be able to blindly apply patch releases, and this breaks that.
I'm even okay with a minor release here. It was never advertised to work that way so removing it technically isn't a breaking change, but there is a known breakage here. I'm much more likely to read minor release notes than patch release notes, so I would likely see this warning if it was a minor release.
Ohhh thanks for the clarification ! As you guessed I'm not into dev/programming so I wasn't aware of this kind of detail !
Thank you :)
Edit: Now semver makes sense !
Yeah, it's really nice when done properly. I have my images pinned to minor releases (they can sometimes break backwards compatibility on accident), so I expect upgrades to newer patch versions to mostly be safe. Mistakes happen, but if 95% of my patch upgrades work w/o intervention, I'll probably enable automatic updates.
As a refresher for others, a semantic version looks like this: X.Y.Z:
You can always bump a "higher" version whenever you like (e.g. 2.0 may not break compatibility w/ 1.0), but never bump a lower version (i.e. bumping Z should never break backwards compatibility). A version bump generally indicates how much I should pay attention to the release notes.