[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: QT 3.0 and future KDR Road Map
From:       Scott Manson <Maniac () Alltel ! net>
Date:       2001-05-29 6:08:37
[Download RAW message or body]

On Monday 28 May 2001 03:51 pm, Waldo Bastian wrote:
> On Monday 28 May 2001 02:34, Bernd Gehrmann wrote:
> > > Having said that, KDE 1 binaries can run run under KDE2 by installing
> > > QT1, kdesupport1 and kdelibs1.  Different library symbols make this
> > > relatively simple (libqt -> libqt2, but an application specifically
> > > linking libqt1 gets it).   Theoretically the same will apply with KDE3
> > > vs KDE2, although it might be a little harder as more active IPC
> > > mechanisms become popular.
> >
> > Reality check? Currently, applications linked with kdelibs from HEAD
> > don't work simultaneously with applications linked with kdelibs 2.1. And
> > that's going to become better?
>
> To be clear: you can't combine libs of the 2.x series. Either all your apps
> use 2.1 libs or all your apps use 2.2 libs, you can't mix.
>
OK please explain why we decided that we can't do what you have described 
above and also keep in mind the following 
Quote from the B/C page of kde.org
A library is binary compatible, if a program linked dynamically to a former 
version of the library continues running with newer versions of the library 
without the need to recompile.
If a program needs to be recompiled to run with a new version of library but 
doesn't require any further modifications, the library is  source compatible 

I have a program that uses kde 2.x libs that runs fine but when a user 
upgrades to kde 2.x+1 and my program refuses to run is that binary 
compatablily?  I don't want to start a flame war here but can we have
a definition of binary compatabilty that makes sense. The present one
doesn't.
Most of my programming experience has been with DOS/Windows and at least 
there if you had a program that ran under version X it usually would also run 
under version X+1 without any problem.  Maybe we shoud take a clue from QT as 
it seems they don't have as many problem(s) kde has; a program compiled/linked
under 2.2 usually works under 2.3, but a program compiled/linked under kde 
2.1 as stated before might not work under 2.2. 

If this is a "major" task to ensure b/c then might I suggest that we 
add/remove some modules to KDELIBS to ensure that anything that ran under kde 
2.1 should also run under 2.2. (assuming that is all it takes.) but I fear 
that this is not as simple as it sounds.  

Maybe I am naive about the current software development cycle but I don't 
think my suggestions ideas are not too far out of line. All I am asking for 
is a "stable" set of libraries to be able to develop other software. The 
current situation does not enable a  developer to do this. Last  week the 
program I wrote works this week (a minor version change to what
my program depends on) it doesn't so I am back to learning what has changed
and how to fix my program to take this into account only to be screwed again 
in another 2-3 weeks (or however long ) when 2.x+1  is released to find my 
program that I wrote successfully, no longer works.  After a few times of 
bashing my head against the wall I will eventually decide that KDE is too 
"unstable" to use and decide to base my program on something else.

GCC/(insert other popular library) doesn't change as often as KDE does.
And IMHO that is a correct correlation KDE supplies an API that other programs
try and use; but due to other program's requirements/features that API gets 
broken then how does one keep a program up to date?
I could see this if we were just writing a single program but we are writing 
a "template" that other programs/programmers  have to use and we should be
doubly carefull that our code is not what breaks other code.

> Getting KDE 2.x running besides KDE 3.x will be a daunting task. It will
> put additional constraints on what we may change in KDE 3.x and I don't
> like that at all. I'm inclined to say that we shouldn't support KDE 2.x
> running in parallel with KDE 3.x at all. Yes, I know that sucks.
The only common thread that ALL developers face is that there are only
24 hours in a day and ANYTHING that would cause something to take more time
(maybe a recompile or a debug session)  should be avoided. My time is 
probably worth less than any 2-3 other developers out there and having to 
recompile the "whole" kit and kaboodle just to get something that worked 
before someone decided to add a new feature is not the way to try and develop.
Does anyone remember trying to develop KDE last year when kde and qt were 
changing almost daily? Yes without the changes KDE wouldn't be where it is 
today but think about the man-hours that were lost to hard to track down bugs
(....is it my program or a library change.) 
Development on a "moving" target is like trying to nail jelly to a wall You 
might get lucky and again you might spend the next week tracking down a bug 
that you don't have enough information about because the libraries you 
developing against are changing faster.
IMHO we must set some sort of failsafe ... KDE WILL always work against 
(insert variable number of libraries/kernels/whatever) and stick to it not
say for this one we need QT 3.whatever but the exact version; and then if 
they release another version we can choose whether we want to support that or 
provide a patch against this particular update.



>
> Cheers,
> Waldo

-- 
Maniac@alltel.net 40° 37' 9" N, 96° 57' 24" W  
A single tasking guy in multi tasking world

[prev in list] [next in list] [prev in thread] [next in thread]