[Kde-extra-gear] backwards compatibility

[Jesper K. Pedersen]

Klas Kalass <klas.kalass at gmx.de> writes:

| 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. 
Well my opinions are not *that* strong, and I do indeed see the trouble of
a large amount of dirs.

Cheers
Jesper.