New release

[Myriam Schweingruber]

Hi all,


On Tue, 14 Apr 2020 at 04:04, Heiko Becker <mail at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20200414/70143e64/attachment.html>