PIM: Version alignment

Mon Sep 19 07:38:14 UTC 2016

> On Saturday 17 September 2016 08:22:20 Ben Cooksley wrote:
>> From their perspective their distribution shipped them Applications
>> 15.10 (as that will be what the release notes say) yet when they got
>> to report a bug they won't find those version numbers.
> 
> This argument is flawed. It ignores that a lot of KDE applications...

No, it's not. Applications that are not released as part of the KDE 
Applications are not mentioned in the release notes of KDE Applications 
[1], where only one version is clearly stated for all applications in 
the list.

> If a user is confused about the version of a specific application, 
> then...

What about developers being confused? For example, dvratil puts tags in 
commit messages like "FIXED-IN: 16.08.1" (see 364994, 356747, 291474, 
340813, 367075, 364342, ...). In contrast, montel uses internal versions 
in these tags.

> If a user is confused about the version of a specific application, then
> a simple check of Help->About <app name> (or an <app> --version on the
> command line) will clarify the version.

Kontact does not have this menu item, just "Introduction to <app name>". 
Although the version number is displayed there, that's not really 
obvious. As a long term user of KDE PIM, I would probably not click on 
any buttons labelled "Introduction...", whether I'm looking for a 
version number or not. CLI skills should not be required for someone to 
report a bug. Besides, my prefered method to check the version of an 
installed package is "eix -ec <package name>" (gentoo specific), which 
at the moment yields "... kde-apps/kmail (16.08.1 (5)...".

Am 16.09.2016 21:55 schrieb David Jarvie:
> The KDE Applications version is simply a date indication. It's very
> useful, for developers who want it, to be able to have an individual
> application version which has a meaning in functional terms.

This is only a valid point for projects where versions mean anything. 
For KDE PIM, the current versioning scheme is 5.A.B as released as part 
of kde-apps-x.y.z, where A is the number of times "x.y" changed since 
15.12, any B = z. So, it can be directly mapped to kde-apps versions if 
you know how, but does not convey any other information than that.

> Moreover, I agree that it's confusing for potential contributors that
> the tags in the repositories do not match the version numbers. This
> should be fixed by creating tags matching the version numbers
> additionally to the KDE_Applications_YY.MM tags. IMO that's also part 
> of
> the maintainers' job for all applications that are part of the KDE
> Applications release, but that do not share the KDE Applications 
> version
> number.

In case the separate versioning scheme is here to stay: +1 for adding 
git tags for internal versions as well, which makes it easier for 
contributors. Alternatively, list versions in bugzilla as in the 
umbrello project, like "2.20.1 (KDE Applications 16.08.1)", which makes 
it easier for contributors AND users.

Regards, Denis

[1] 
https://www.kde.org/announcements/fulllog_applications.php?version=16.08.0