> * The difficulty of coding for N releases. Since the releases an not aligned > anymore, you have to maintain code and #ifdefs for new features that depend on > new versions of parts X of the stack that may or might not be used by people > compiling the application. We've have some bad experiences with "expected > versions on the stack" so i hope you're understanding this is not a > theoretical scenario.
i thought about that as well, but assuming kdelibs is the only issue, i was assuming that the kdelibs releases would always be ahead of the everything-else releases. in which case there should be no "i have a feature that requires XYZ from kdelibs", or something. or were you referring to other areas of the stack? i could see it becoming a problem if we have some apps with dbus trying to talk with each other when they're on totally different release schedules. but that's not too difficult to solve. -- Shaun Reich, KDE Software Developer (kde.org)