Re: KDE Applications Versioning
On Tue, Jun 9, 2015 at 11:35 AM, David Jarvie djar...@kde.org wrote: There has been debate about this for frameworks, and there is an argument there (not agreed by everybody) for making all frameworks have the same version, since framework libraries are dependencies for other software. The same arguments don't apply to applications, which in general are not dependencies. Other than convenience for maintainers who forget to update version numbers, I can see no good reason for forcing applications to have a uniform version number. I prefer using the version number to reflect the development status of the application (by use of major, minor and patch version numbers), as in the past. This makes it easier when dealing with bug reports, to know the state of the program at the version in question. For maintainers who want to use some other scheme, that's also fine. The important thing is to leave the choice. Personally I prefer having the application versions matching the release version (ie. 15.04.x) so that there is no additional versions mapping required (is version 3.4 part of KDE Applications 15.04 or 15.08 or..?). So I for one would also welcome such feature, but can absolutely relate to David's position too; the versioning should not be forced on Applications. So this could be easily made opt-in by using some predefined CMake variable and projects having such var would get the version raised by the scripts. +1 to that idea. Hi, I don't want to force people to use it, just to have always existing and updated KDE_APPLICATIONS_ variables around for people wanting to use them. And I think it makes sense to use them for a lot apps, given not many apps have any real version number updates it seems ;=) (it makes bug reports much nicer, if you can actually track the bug to some released version) 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, June 8, 2015 11:32 pm, Aleix Pol wrote: 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 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? There has been debate about this for frameworks, and there is an argument there (not agreed by everybody) for making all frameworks have the same version, since framework libraries are dependencies for other software. The same arguments don't apply to applications, which in general are not dependencies. Other than convenience for maintainers who forget to update version numbers, I can see no good reason for forcing applications to have a uniform version number. I prefer using the version number to reflect the development status of the application (by use of major, minor and patch version numbers), as in the past. This makes it easier when dealing with bug reports, to know the state of the program at the version in question. For maintainers who want to use some other scheme, that's also fine. The important thing is to leave the choice. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: KDE Applications Versioning
On Tue, Jun 9, 2015 at 11:35 AM, David Jarvie djar...@kde.org wrote: There has been debate about this for frameworks, and there is an argument there (not agreed by everybody) for making all frameworks have the same version, since framework libraries are dependencies for other software. The same arguments don't apply to applications, which in general are not dependencies. Other than convenience for maintainers who forget to update version numbers, I can see no good reason for forcing applications to have a uniform version number. I prefer using the version number to reflect the development status of the application (by use of major, minor and patch version numbers), as in the past. This makes it easier when dealing with bug reports, to know the state of the program at the version in question. For maintainers who want to use some other scheme, that's also fine. The important thing is to leave the choice. Personally I prefer having the application versions matching the release version (ie. 15.04.x) so that there is no additional versions mapping required (is version 3.4 part of KDE Applications 15.04 or 15.08 or..?). So I for one would also welcome such feature, but can absolutely relate to David's position too; the versioning should not be forced on Applications. So this could be easily made opt-in by using some predefined CMake variable and projects having such var would get the version raised by the scripts. +1 to that idea. Cheers -- Martin Klapetek | KDE Developer
Re: KDE Applications Versioning
On Tue, Jun 9, 2015 at 12:12 PM, Christoph Cullmann cullm...@absint.com wrote: Personally I prefer having the application versions matching the release version (ie. 15.04.x) so that there is no additional versions mapping required (is version 3.4 part of KDE Applications 15.04 or 15.08 or..?). So I for one would also welcome such feature, but can absolutely relate to David's position too; the versioning should not be forced on Applications. So this could be easily made opt-in by using some predefined CMake variable and projects having such var would get the version raised by the scripts. +1 to that idea. I also think using two different version numbers is potentially confusing to users. For Ark, we will use the Applications version from 15.08 onwards. Regards, Ragnar
