Proposed adjustments to our release cycles

[Shaun Reich]

>  * 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)