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

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

Reply via email to