[Kde-extra-gear] backwards compatibility

[Klas Kalass]

Am Montag, 26. Januar 2004 17:30 schrieb George Staikos:
> On Monday 26 January 2004 02:27, Klas Kalass wrote:
> > > > The problem is, that the entire module cannot be compiled if there
> > > > was a MIN_CONFIG(3.1). The occasional developer should still be able
> > > > to check out the stuff in the extragear modules and fix things.....
> > >
> > >    Requiring KDE 3.2 or higher is basically never going to be
> > > acceptable for Kst.  If that happens, we will need to find alternate
> > > arrangements. If individual apps can't specify which minimum KDE
> > > version they require, maybe we need a different approach to
> > > partitioning the applications in CVS.
> >
> > Is it unacceptable that the module as checked out requires it, or is it
> > unacceptable that when doing releases, care must be taken to configure
> > your applications release for the correct KDE version?
>
>    Well changing the minimum required version when building packages isn't
> so bad, but then it is 99% likely that all the developers will be using 3.2
> which means that testing will not happen on 3.1.  It's also extremely
That would be unfortunately indeed.

> annoying for developers to have to edit the configure.in.in file, and for
> users who run out of CVS to have to do the same.
I agree, but isn't it even worse if applications are shuffled around seemingly 
randomly?

As of now I see 2 solutions: 
1) Use the highest requirement off all applications for the entire module
    and let every application maintainer drop the requirements for a release
    or in their working directory. This solution is the least pain for those  
    users likely to use CVS: People who use the latest stable KDE.
    This implies that no application is allowed to require CVS which used to 
    be the implicit rule up to now anyways.

2) divide the modules by KDE version.
   This would get very messy: 
    a) we still use kdeextragear-* as name: -1 might mean KDE 3.1 and -2 might 
mean KDE 3.2, while -3 might mean HEAD. After some time applications start to 
be shuffled around, -2 will get full and -4 will be open. Now think what is 
going to happen if KDE 3.3 is released. You cannot even guess from the name
of the module why an application was moved.
b) we use kdeextragear_3_x-n as name: If we keep -n constant for each 
application, there will be a fair chance of finding applications. Still, 
applications would be shuffled around and some modules would grow larger and 
others would decline. This solution would eventually mean a huge amount of 
modules.

From the postings I only see two clear statements: Jesper favours solution 2 
(a or b?) and I favour solution 1. 

Is there another possibility? What solution is favoured by the majority?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : http://mail.kde.org/pipermail/kde-extra-gear/attachments/20040127/9070bfff/attachment.pgp