kdesupport Policy

[Dirk Mueller]

On Tuesday 26 August 2008, Michael Pyne wrote:

> Well what I was thinking is we could make a kdesupport 4.1 branch for
> instance to do the same thing. (unless you mean kdesupport-stable which
> simply tracks the latest stable release of KDE).

It doesn't make sense to me - the software in kdesupport is not released on 
the same schedule like KDE, and often enough newer versions work just fine with 
older versions of KDE. There are rare exceptions, like the horrific strigi 
backward incompatibility (that could have been solved in the source code with 
less work than this thread already took). 

> And then a kdesupport/kde-trunk or something for /trunk development.

Lets put it the other way around: not having the connection between kdesupport 
and KDE helps in a way that:

a) cmake checks are excerized and updated to match the actual version 
requirements of the 3rd party packages we rely on, which in return helps users 
and packagers.

b) distros can provide packages for KDE developers so that they do not have to 
build all of their system from scratch. 

c) software is in kdesupport because we want it to be easy to pick up for non-
KDE projects (otherwise if is a KDE only dependency it should be in KDE). This 
also means that we should provide tarballs, documented release schedules, 
feature plans, compatibility matrixes for it etc. 


I think what is missing here is regular snapshots of things that should be 
used for /trunk development, and a timeline on when they're required (e.g. 
only on mondays). 

Greetings,
Dirk