[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: Proposed adjustments to our release cycles
From:       Shaun Reich <sreich () kde ! org>
Date:       2012-06-17 23:09:22
Message-ID: CADVynFBNnmjjN3GSLyJgG8LwRqQdkACKnqR74CAikW6N+2RGRA () mail ! gmail ! com
[Download RAW message or body]

> =A0* The difficulty of coding for N releases. Since the releases an not a=
ligned
> anymore, you have to maintain code and #ifdefs for new features that depe=
nd on
> new versions of parts X of the stack that may or might not be used by peo=
ple
> 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)
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
[prev in list] [next in list] [prev in thread] [next in thread]