Bug reporting for KDE 4

[David Jarvie]

On Tuesday 30 October 2007 1:11, Ingo Klöcker wrote:
> On Monday 29 October 2007, Will Stephenson wrote:
>> I propose that all apps in the KDE 4 release cycle drop their custom
>> version strings and use $KDE_VERSION instead.  What am I missing that
>> prevents us from doing so?
>
> Do you mean $KDE_VERSION as in MAJOR.MINOR or as in
> MAJOR.MINOR.PATCH-LEVEL?
>
> Anyway, I considered doing something similar, i.e. using kdelibs
> $PATCH_LEVEL, for KMail each time I forgot to increase KMail's version
> number before a new KDE release, but after thinking about the
> implications I always dismiss this idea again very quickly.
>
> One reason against this is that the version string would reflect the
> version of kdelibs the app was compiled against which might have little
> to do with the actual version of the app. Granted this is mainly a
> problem for people trying out the bleeding-edge svn version of an
> application compiled against the latest stable release of kdelibs.
>
> Another reason is that this would make it more difficult to increase the
> patch-level number of an application in between of normal KDE releases
> to mark an important bugfix. (We'd have to use hacks like $KDE_VERSION
> + 1 to do this.) This has already been done at least once for KMail so
> this isn't a purely hypothetical argument.
>
> Last but not least, I'm strictly against jumping from version 1.9.x to
> version 4.0.0 in KMail. As far as I'm concerned KMail 1.10.0 will be
> part of KDE 4.0.0. KMail 2 should be reserved for the switch to Akonadi
> (i.e. hopefully KDE 4.1).

I agree with Ingo. KAlarm usually has intermediate releases between KDE
versions, which would cause the version numbering problems as Ingo
describes. And I also would rather jump major and minor version numbers
when the application's features indicate it - this doesn't always tally
with KDE version changes.

-- 
David Jarvie.
KAlarm author & maintainer.
http://www.astrojar.org.uk/kalarm