PIM: Version alignment

[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.

-- 
David Jarvie.
KDE developer.
KAlarm author - http://www.astrojar.org.uk/kalarm