PIM: Version alignment

[Denis Kurz]

Versions like "5.3.1 (KDE Applications 16.08.1)" seem to cause problems 
of their own, see this bug comment:

> https://bugs.kde.org/show_bug.cgi?id=369339
> 
> --- Comment #1 from Christophe Giboudeaux <cgiboudeaux at gmx.com> ---
> I won't be adding the 'KDE Applications...' part. This is troublesome 
> when
> using the drkonqi reporting tool (help/report bug)
> 
> --
> You are receiving this mail because:
> You reported the bug.


Am 20.09.2016 10:55 schrieb David Jarvie:
> On Mon, September 19, 2016 8:38 am, denis.kurz at posteo.de wrote:
>>> 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.
> 
> I've never found a problem in bug reports arising from using a separate
> application version. The version related problems in bug reports are
> usually trying to establish which Frameworks version, which desktop,
> desktop version and distro version the user has installed.
> 
>> 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.
> 
> As far as I'm concerned, it should be up to each application's 
> maintainer
> whether to use the KDE Applications version number or their own 
> version.
> In the latter case, the version can mean whatever they find useful.
> 
> KDE is not a monolithic piece of software, and it shouldn't try to 
> behave
> like one by forcing individual applications to adopt what is 
> essentially
> an arbitrary version number which has no relationship to the 
> application's
> development status. The KDE Applications release is just a convenient
> bundling of a bunch of Frameworks based applications in various stages 
> of
> development - some might have major feature changes, while others might
> have just the odd bugfix, and some might be unchanged since the last 
> KDE
> Applications release.
> 
> In the end, I regard this as a (small) issue of freedom. Yes, 
> applications
> need to comply with some basic KDE standards if they are to be part of 
> KDE
> Applications, but this is taking central diktat a step too far.
> 
>> 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.
> 
> That seems a good idea. Adoption of a standard way of setting the
> application's version would then, in theory at least, enable Bugzilla 
> to
> be scripted to add new release versions in that format.