KDE Applications Versioning

2015-06-08 Thread Christoph Cullmann
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

2015-06-08 Thread Aleix Pol
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

2015-06-08 Thread David Faure
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

2015-06-08 Thread Ben Cooksley
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