KDE Gear 24.12.0 packages available for packagers

[Ben Cooksley]

On Mon, Dec 9, 2024 at 12:13 AM Neal Gompa <ngompa13 at gmail.com> wrote:

> On Sun, Dec 8, 2024 at 5:48 AM Tobias Leupold <tl at stonemx.de> wrote:
> >
> >
> > E-Mail von Albert Astals Cid vom Sonntag, 8. Dezember 2024, 11:19:21 MEZ:
> > > El divendres, 6 de desembre del 2024, a les 13:58:01 (Hora estàndard
> del
> > > Centre d’Europa), Tobias Leupold va escriure:
> > > > E-Mail von Heiko Becker vom Freitag, 6. Dezember 2024, 13:50:51 MEZ:
> > > > > On Friday, 6 December 2024 12:08:46 CET, Christophe Marin wrote:
> > > > > > Slightly related to this release, packagers need to know what to
> do
> > with
> > > > > > packages depending on Qt 5 and marble:
> > > > > >
> > > > > > - kgeotag (1.6.0 release only supports KF5/Qt5)
> > > > > > - kphotoalbum (5.13 release  only supports KF5/Qt5, but the
> > > > > > marble dependency
> > > > > > is optional)
> > > > > > - kexi (no release for the past 5 years)
> > > > >
> > > > > Just to add some piece of information here, because one could get
> the
> > > > > impression that Marble is a hard dependency of kexi. Actually it's
> > > > > optional
> > > > > as well. And while the current release searches for (Kexi)Marble,
> the
> > > > > respective subdir is commented out (and still is in git master),
> so I'd
> > > > > say
> > > > > it doesn't depend on marble at all the moment.
> > > > >
> > > > > > - kreport (no release for the past 5 years)
> > > > >
> > > > > It's an optional dependency there, too.
> > > > >
> > > > > > I'm not expecting users will notice if we drop kexi and kreport,
> but
> > > >
> > > > having
> > > >
> > > > > > solutions for the other ones before the 24.12 release would be
> nice.
> > > > >
> > > > > Seems we're not particular good at foreseeing such things...
> > > > > Six days isn't much time, but I added Tobias in CC to hear if a
> soonish
> > > > > release of a Qt6-based kgeotag may be realistic.
> > > > >
> > > > > Regards,
> > > > > Heiko
> > > >
> > > > PS: Maybe also important: The next KGeoTag release will be buildable
> both
> > > > against Qt6/KF6 as well as Qt5/KF5, whereas the next KPA release
> will be
> > > > Qt6/ KF6-only.
> > >
> > > Unless you really really have a reason to support both Qt5 and Qt6
> (i.e.
> > it's
> > > a plugin or library) I would really suggest you support just one (Qt6
> > > preferably).
> >
> > Hi Albert,
> >
> > for KGeoTag, it was no big deal to keep it compatible with both Qt 5 and
> Qt 6
> > (not so for KPA), so I thought it wouldn't hurt for now? At least as
> long as I
> > can still use Qt 5 on my Gentoo box or using some LTS distro VM (like the
> > oldest still-maintained Ubuntu or such, the plan was to support Qt 5
> until
> > Ubuntu LTS is Qt-6-based if possible).
> >
> > Of course it would be no problem to drop Qt 5 compatibility with the next
> > release, this would strip down to removing the respective parts of
> > CMakeLists.txt along with that one QT_VERSION_CHECK macro call in
> main.cpp I
> > needed.
> >
> > But just to understand the reasoning: Why is it bad to still support Qt
> 5 if
> > it's possible without noteworthy effort?
> >
>
> Because it creates drag for the rest of the project infrastructure.
> Dropping Qt 5 stuff in infrastructure is a priority since Qt 5 is
> effectively unmaintained and it's hard to do if KDE projects aren't
> moving to Qt 6.
>

I'll echo both Albert and Neal's sentiments here.

Keeping anything Qt 5 around is essentially dead weight that imposes a
variety of not immediately obvious costs which would be better spent
focusing on new things rather than keeping Qt 5 on life support.


>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>

Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20241209/ba917df3/attachment.htm>