Hi all,
On Tue, 14 Apr 2020 at 04:04, Heiko Becker <m...@heiko-becker.de> wrote: > Hey Pedro and all, > > On Sonntag, 12. April 2020 09:51:33 CEST, Pedro de Carvalho Gomes wrote: > ... > > Myriam asked for a release as well. It's not much work to create and > release a tarball and I'm happy to do it, but I'm bit concerned about > expectations. IMHO it should "only" be an alpha release. That makes perfect sense, I was even suggesting it to be a technical preview, but that's roughly what alpha is anyway There are still > rough edges and one problem (besides the mentioned mysqle issue) is > scripting. QtScript is deprecated and will go away and there are currently > no Qt5 bindings for it anyway. Possible solutions are > > - Get rid of it alltogether > - There's a patch on phab to add bindings extracted from Qcad which still > uses QtScript, https://phabricator.kde.org/D24817 and needs at least some > license headers and some glue > - Port to the QJS* classes from QtQml (one simple example for a Plasma > runner [1]) Any opinions on that? The initial idea was always to port it, so QJS makes perfect sense, but will also make this more work ... > > I went after Mariadb's plans for the embedded library. I couldn't find > > any mention to it. Only references to 10.5 series mirroring Mysql 8, > > which is the version that dropped Mysql embedded. However Mariadb 10.4 > > contains the embedded library, and is supported until June 2024 (see > > https://mariadb.com/kb/en/new-and-old-releases/) > > I just checked out the 10.5 branch of Mariadb and it looks like the > embedded server is still present there. > > > I wonder if Amarok could release a version with dependency to Mariadb > > <= 10.4. Then we prioritize the port to the alternative to > > mariadb/mysql. This would bridge the 2-year gap from the previous > > release. Also it would bring Amarok back to distros that are not > > shipping it because it doesn't have an official KF5 versions (namely > > Ubuntu). > > I think there's no need to declare such a dep on our side at the moment. > It > sufficient to check if it's present or not in our cmake code, which we > already do. > > +1 from me here too, we should not hardcode a dependency. But the issue might be that some distros don't ship this version yet, so a warning needs to be issued to the distros on release announcement Nice to see some movement here, thanks a bunch to all who make this happening :-) FWIW: we still have a Development channel on IRC: #amarok.dev, please use it instead of #amarok which is meant for user support Stay safe an healthy everyone! Regard, Myriam -- Proud member of the Amarok and KDE Community Protect your freedom and support the work of the FSFE: http://www.fsfe.org <http://www.fsfe.org/> Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300)