On Jul 22, 2014 12:30 AM, "Frank Reininghaus" <[email protected]> wrote: > > 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
Maybe the list could have multiple levels, such as "not ported", "unstable", "not feature-complete", "waiting", and "included". Even if not available by default, distros may still want to have stable ported applications available to users as an optional alternative.
