Re: How my BBC Sounds Plugin briefly broke LMS. A cautionary tale!

I would absolutely agree that platform support is becoming a bit long in 
the tooth. Not only for the many combinations of OS/CPU/Perl versions. 
But eg. for Windows and macOS, too!

- Windows: we're using ActiveState Perl Development Kit's (PDK) PerlApp 
and siblings, based on ActivePerl 5.14. ActiveState recommends to NOT 
use the PDK any more. They actually suggest applications should be run 
using Docker. Which IMHO isn't an option for us on Windows (yet).

- macOS has long stuck with Perl 5.18. Only in Mojave they installed 
5.28. On Big Sur we have 5.30 in addition to the previous two. With 
Apple's switch to the M1 CPU we're additionally facing the fact that we 
don't have the platform support yet. I tried to build dependencies for 
5.30 on M1 but failed (so far).

- macOS and Windows come with some additional tools, like a tray bar, or 
the preference pane. In particular the macOS PrefPane is in dire need of 
some love: I'm still running builds in a MacOS 10.5(!) VM using the old 
XCode from back then, because newer version wouldn't compile any more...

- Linux: much discussed dependency hell.

So there's much more work than I can handle. And as long as things run...

> Officially (supported) Debian systems are Stretch and Buster. Stretch comes
> with perl 5.24 and Buster comes with 5.28. So it is reasonable to drop
> everything older than 5.24.

It's not that easy. Some platforms aren't as well supported as the Pi, 
and updates come in slower. Even NAS vendors tend to update slowly. 
People keep their NAS around for years. Yes, we can drop them, and I'm 
trying to get people to use a Pi instead. But for many this still is 
"too techy". I'm looking forward to seeing PolyVection's offering.

Anyway: the good news is that nothing stops you and/or other community 
members from coming up with new build scripts, or package definitions or 
whatever they're called, to create a lean .deb package fully relying on 
external dependencies. It looks as if somebody had done it for NixOS 
(see https://github.com/Logitech/slimserver/issues/138).

I'd be happy to provide such a "clean" .deb package in addition to 
today's offerings - it could replace the old builds in the longer term. 
But I can't handle it. If you want LMS to change the way you're so vocal 
about, then you'll have to get your hands dirty. As of today there are 
only a few contributors to LMS itself, and they concentrate on core 
functionality.

> Assume LMS 10 would be a breaking new version. If the current 8.x do not
> automatically update I do not foresee big problems.

FWIW: it's very unlikely there will ever be a LMS 10. As with Windows 9, 
that number has been burnt in other ways. The "UE Media Library", 
supporting the UE Smart Radio, internally used that version number. But 
then, maybe by the time we get to v10 UEML is history, and nothing is 
left from it. By the current pace of major updates it won't happen in 
this decade anyway :-D