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
