KDE Applications December 2014 release: which apps are targeting Qt4/Qt5?

[Frank Reininghaus]

Hi,

2014-07-21 23:34 GMT+02:00 Albert Astals Cid:
> El Dilluns, 21 de juliol de 2014, a les 13:26:32, Frank Reininghaus va
> escriure:
>> Hello everyone,
>>
>> after KDE SC 4.14, the next release of the KDE applications that are
>> part of the KDE SC is planned for December. It will contain not only
>> applications that are still based on Qt4+kdelibs 4.x, but also
>> applications that have the first stable release of their Qt5+KF5 ports
>> [1]. All application developers/maintainers can decide if they want to
>> release another Qt4+kdelibs 4.x-based version, or if they want to
>> release their first Qt5+KF5-based version.
>>
>> I think it would be helpful if there was a central site where
>> information about the choices that developers have taken so far is
>> collected, i.e., a place where everyone can look up quickly if
>> application XYZ will have a Qt4-based or a Qt5-based release, or if it
>> is still in the "not decided yet" state. One of the reasons why I
>> consider such a thing useful is that quite a few applications have
>> runtime dependencies that are provided other applications. For
>> example,
>>
>> * Many applications have an embedded terminal, which is provided by
>> the Konsole KPart. If Konsole does not release a Qt5-based version in
>> December, then any application which does will not have an embedded
>> terminal any more.
>>
>> * All of Konqueror's functionality is provided by KParts that are
>> provided by libraries and applications and that are loaded at runtime.
>> If some of these KParts will not have a Qt5-based release, then the
>> functionality of a Qt5-based Konqueror would be severely limited.
>>
>> There are probably many more (and less obvious) examples of such
>> run-time dependencies. Releasing these Qt5-based applications without
>> their runtime dependencies will result in feature loss, and I'm afraid
>> that this might lead to some users, who will probably expect a smooth
>> transition to Qt5+KF5 because they can read everywhere that the port
>> should be much simpler than the Qt3->Qt4 transition was (except for
>> projects which take the opportunity to make some other architectural
>> changes at the same time, such as Plasma) and the media saying "It's
>> the old KDE 4.0 story again". I think that we should try to prevent
>> that, and I believe that a central site where everyone can look up the
>> release plans of all applications would be helpful.
>>
>> I've created a draft of a wiki page where this information could be
>> collected at
>>
>> https://community.kde.org/User:Freininghaus/draft-Qt4-Qt5-application-overvi
>> ew
>>
>> What do you think about this idea? If there is agreement that my idea
>> makes sense, I would move this page to a suitable place (maybe
>> https://community.kde.org/Frameworks/Application-release-status-December-201
>> 4 ?) and send a message to k-c-d and kde-devel, asking all
>> maintainers/core developers to fill in any relevant information that
>> they already have.
>
> I'm not against it, having some kind of central place to coordinate makes
> sense.
>
> OTOTH i would only expect a maintainer to port stuff to KF5 if he knows the
> dependencies of its app are ported or are going to be ported by the required
> timeframe

I fully agree :-)

But at the moment, there is, to my knowledge, no easy way to find out
if there will be a stable Qt5/KF5-based release of the dependencies in
December 2014. This is the reason why I proposed to collect this
information in a central place.

Note that it's *not* enough that a dependency is ported to KF5. If the
maintainer of that dependency decides that they prefer to have another
kdelibs 4.x-based release in December in order to give the KF5 port
some more time to mature, then users of most distros, which only ship
stable releases of our software unless the user explicitly enables
some extra package repositories, would still have no access to
dependency. Any KF5-based application that tries to use that
dependency at run time would lose features, and preventing that is
just what I'm trying to achieve with this effort.

Thanks and best regards,
Frank