Bug reporting for KDE 4

Ingo Klöcker kloecker at kde.org
Tue Oct 30 01:11:41 GMT 2007


On Monday 29 October 2007, Will Stephenson wrote:
> On Monday 29 October 2007, Dirk Mueller said:
> > > There is also quite some confusion about where/if/how to report
> > > them Bugzilla?
> >
> > bugs.kde.org is your choice :)
>
> So b.k.o is theoretically the ideal tool but users and developers are
> confused/inhibited from using it (probably because with the exception
> of one or two saintly people we're all in denial about the number of
> KDE 3 bugs it contains).
>
> My hunch is that this is because it's never clear which applications'
> versions correspond to a given prerelease of KDE 4.  Most (IMO) apps
> have their own versioning scheme.  As well as creating confusion,
> this prevents release-team from querying for 'all the bugs in
> 4.0rc42'.
>
> 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).


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071030/8f077e80/attachment.sig>


More information about the kde-core-devel mailing list