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 _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
