KDE Applications Versioning
Hi, for frameworks, it is all very nice and automatic, the version in the CMakeLists.txt get auto-updated on each KF 5.x release. It seems to me, for the applications collection, something similar might make sense. E.g. I missed to ever update the Kate version since 5.0 and other applications like Dolphin and Konsole seem to have similar problems. Would it make sense to have some we auto-define some version CMake var to KDE Application release number? For e.g. bug reports that would make all things easier. Or do I miss some magic already in place (e.g. the opensuse packages seems to have patched release numbers, at least for Konsole). Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: KDE Applications Versioning
On Mon, Jun 8, 2015 at 8:25 PM, Christoph Cullmann cullm...@absint.com wrote: Hi, for frameworks, it is all very nice and automatic, the version in the CMakeLists.txt get auto-updated on each KF 5.x release. It seems to me, for the applications collection, something similar might make sense. E.g. I missed to ever update the Kate version since 5.0 and other applications like Dolphin and Konsole seem to have similar problems. Would it make sense to have some we auto-define some version CMake var to KDE Application release number? For e.g. bug reports that would make all things easier. Or do I miss some magic already in place (e.g. the opensuse packages seems to have patched release numbers, at least for Konsole). Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 I'd welcome such feature. I always forget to update my applications' version. Maybe it would be best to ask the release-t...@kde.org? Aleix
Re: building kio on Mac
That wasn't very constructive/positive... On Monday 08 June 2015 15:22:20 Ben Cooksley wrote: The Qt developers didn't want to provide any infrastructure at all to make developer environments (including our CI system) easier. The *any* here is too broad. One approach was rejected, there are tons of others. E.g. just naming the variables QT_ instead of XDG_ might have been less controversial. But since everyone was saying, at the same time, that end users don't want env vars, I can understand that the Qt developers thought this issue needs more thinking, to solve all uses cases, not just KDE CI (which was a too restrictive line of argumentation compared to what it really was, developer setup, as you say). The maintainer(s) of the QStandardPaths class never reviewed our patch That would be me, and since I don't know how things should work on OSX, I am not in a good position to decide. On top of that I come from the KDE world, so I can't really force a KDE patch into Qt if it's a bit controversial. , and the module maintainer for QtCore wanted the opinion of a Digia employee who was extremely unresponsive. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: building kio on Mac
On Mon, Jun 8, 2015 at 7:13 PM, David Faure fa...@kde.org wrote: That wasn't very constructive/positive... Sorry, i've spent way too much time fighting with the Qt folks on this one. On Monday 08 June 2015 15:22:20 Ben Cooksley wrote: The Qt developers didn't want to provide any infrastructure at all to make developer environments (including our CI system) easier. The *any* here is too broad. One approach was rejected, there are tons of others. E.g. just naming the variables QT_ instead of XDG_ might have been less controversial. Thiago rejected that approach immediately when I suggested it over IRC. He basically said it was XDG_* or nothing, and won't allow XDG_* to proceed unless it is given the okay by the previously mentioned unresponsive Digia employee. As maintainer of QtCore he holds veto rights in this instance I believe. But since everyone was saying, at the same time, that end users don't want env vars, I can understand that the Qt developers thought this issue needs more thinking, to solve all uses cases, not just KDE CI (which was a too restrictive line of argumentation compared to what it really was, developer setup, as you say). The maintainer(s) of the QStandardPaths class never reviewed our patch That would be me, and since I don't know how things should work on OSX, I am not in a good position to decide. On top of that I come from the KDE world, so I can't really force a KDE patch into Qt if it's a bit controversial. That makes sense. , and the module maintainer for QtCore wanted the opinion of a Digia employee who was extremely unresponsive. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 Regards, Ben