--001a11393df676bcb504fec49c59 Content-Type: text/plain; charset=UTF-8 On Jul 22, 2014 12:30 AM, "Frank Reininghaus" 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. --001a11393df676bcb504fec49c59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 22, 2014 12:30 AM, "Frank Reininghaus" <frank78ac@googlemail.com> 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 Reiningha= us va
> > escriure:
> >> Hello everyone,
> >>
> >> after KDE SC 4.14, the next release of the KDE applications t= hat are
> >> part of the KDE SC is planned for December. It will contain n= ot only
> >> applications that are still based on Qt4+kdelibs 4.x, but als= o
> >> applications that have the first stable release of their Qt5+= KF5 ports
> >> [1]. All application developers/maintainers can decide if the= y want to
> >> release another Qt4+kdelibs 4.x-based version, or if they wan= t 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 f= ar is
> >> collected, i.e., a place where everyone can look up quickly i= f
> >> 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. Fo= r
> >> example,
> >>
> >> * Many applications have an embedded terminal, which is provi= ded by
> >> the Konsole KPart. If Konsole does not release a Qt5-based ve= rsion in
> >> December, then any application which does will not have an em= bedded
> >> 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, th= en the
> >> functionality of a Qt5-based Konqueror would be severely limi= ted.
> >>
> >> There are probably many more (and less obvious) examples of s= uch
> >> 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 t= he port
> >> should be much simpler than the Qt3->Qt4 transition was (e= xcept for
> >> projects which take the opportunity to make some other archit= ectural
> >> changes at the same time, such as Plasma) and the media sayin= g "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 lo= ok up the
> >> release plans of all applications would be helpful.
> >>
> >> I've created a draft of a wiki page where this informatio= n could be
> >> collected at
> >>
> >> https://community.kde.org/User:Freininghaus/dra= ft-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 (mayb= e
> >> https://community.kde.org/Frameworks/Applicatio= n-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 informati= on that
> >> they already have.
> >
> > I'm not against it, having some kind of central place to coor= dinate 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 t= he required
> > timeframe
>
> I fully agree :-)
>
> But at the moment, there is, to my knowledge, no easy way to find out<= br> > 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<= br> > 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", &quo= t;waiting", and "included".=C2=A0 Even if not available by d= efault, distros may still want to have stable ported applications available= to users as an optional alternative.

--001a11393df676bcb504fec49c59--