I posted this patch already at Review Board about one year ago.
https://git.reviewboard.kde.org/r/128536/
After a short (from my point of view positive) discussion it fell asleep.

But I still found it useful and put it up for discussion again. Recently I read a lot in Parleys bug reports and found out for me, that a never changing version number is not very useful. So with a minimum of effort Parley shows always a up-to-date version string with this solution.

Can you please have a look at the "Bugzilla versions" part because otherwise all those bugs are going to end up in the "undefined" version category when reported through about->report bug or drkonqui

OK I see.

Since cmake wants the version string in this format: VERSION <major>[.<minor>[.<patch>[.<tweak>]]], a more complex version string, which include both, parleys version string and the complete KDE Applications version string, is not practicable. Using the KDE Apps micro version as extension to parleys version, as shown in the guide as example, seems to be no advantage to me. Since the micro version repeats every release.

So I see only two ways. Leave it as it is or use only the KDE Apps version string.

I lean towards the second way. But may there is a third way, which I do not see...
What do you think?

In D10394#203970, @hriesenbeck wrote:

OK I see.

Since cmake wants the version string in this format: VERSION <major>[.<minor>[.<patch>[.<tweak>]]], a more complex version string, which include both, parleys version string and the complete KDE Applications version string, is not practicable. Using the KDE Apps micro version as extension to parleys version, as shown in the guide as example, seems to be no advantage to me. Since the micro version repeats every release.

So I see only two ways. Leave it as it is or use only the KDE Apps version string.

I lean towards the second way. But may there is a third way, which I do not see...
What do you think?

The bottom line here, is someone needs to care about the application version. Right now noone is, so it's stuck in 2.1.0 for 2 years.

If you're willing to commit the changes, you can manually increase the version before each release (we have a calendar for that).

If you're not (and i understand that, not trying to blame you or anything) you must use an automatic way like we're trying in this code review.

You're right that the auto increasing micro version like we do in Okular still needs manual intervention for each "non point" release.

If we don't want to do that we must use a totally automatic way to do it, that is using KDE_APPLICATIONS_VERSION directly, or if we were to be nasty i guess one could do some calculation like 2.X.KDE_APPLICATIONS_VERSION_MICRO where X is (KDE_APPLICATIONS_VERSION_MAJOR-16)*3+KDE_APPLICATIONS_VERSION_MINOR/4 (math to be checked this actually produces an increasing version number). But I'm not sure that really sounds like a good idea either, so i'll leave it up to you:
a) You commit to increase the version for every release
b) You commit to increase the version for every non-point release and just use KDE_APPLICATIONS_VERSION_MICRO
c) You perfect my formula and convince me it won't break and it's a good idea
d) We use KDE_APPLICATIONS_VERSION directly

Any of the options is good for me. Anyone else at @kde-edu has an opinion?

Thank you for your reply, Albert.
I would prefer using KDE_APPLICATIONS_VERSION directly and drop parleys version completely.
Since parleys version is written to its KVTML files and hypothetical there would be changes of the file format somewhere in future, it would be easy to detect because the recent KDE Apps version is bigger than parleys current version 2.1.0.
I will update the patch soon.

If noone disagrees i'll accept this revision in two weeks :)