[Kde-pim] Make KDE PIM 4 installable in parallel to KDE PIM 3

[Allen Winter]

On Thursday 01 November 2007 12:52:21 Jason 'vanRijn' Kasper wrote:
> On 10/21/07, Allen Winter <winter at kde.org> wrote:
> > If there are KDEPIM4 apps that are cause data loss or *really suck*
> > then we I think we simply shouldn't build them in the toplevel
> > CMakeLists.txt.
> >
> > Which reminds me of an idea I had...  we could have stuff like this in
> > our top-level CMakeLists.txt files to exclude apps that aren't "
> > KDE4.0-ready"
> >
> > if (NOT ${KDE_ENABLE_FINAL})
> > add_subdirectory(appfoo)
> > endif(NOT ${KDE_ENABLE_FINAL})
> >
> > then appfoo won't be built if the distro packagesuse 'cmake
> > -DKDE_ENABLE_FINAL'.
>
> I didn't see a firm resolution on this particular idea, but I think it (or
> something very much like it) might have merit to my current situation.  In
> particular, kpilot is suffering from a severe lack of attention right now,
> despite my best intentions.  With Adriaan in denial (=;P), Bertjan back in
> school, and me 2 weeks into a brand new job (woohoo) on the other side of
> the continent with lots of time-consuming Real Life (TM) pending, I need to
> figure out what to do with kpilot for 4.0 release.
>
> Specifically, there are some conduits that I don't want to take out of the
> normal compile/build process (otherwise they'll get even more broken as
> changes are made in pim and elsewhere that won't get reflected in kpilot's
> conduits), but I wouldn't want them to be included in an official release
> due to possible data issues.
>
> One option that would be trivial to implement would be to put early return
> code into these conduits so that they put "sorry, this conduit isn't fully
> functional yet" into the user's Palm sync log and don't risk damage to any
> data.  My issue with this approach, though, is that the user is mislead to
> think that the conduit is functional in the setup/configuration screen and
> won't know that his/her data wasn't synced correctly unless they happen to
> look in their sync log.
>
> So, I was thinking that Allen's idea might be an option for me to disable
> some of these not-yet-ready-for-prime-time conduits in a production build.
> And, as I stated in an earlier thread, I don't want to disable kpilot
> entirely from a release build because it does bring forward some
> functionality from kde3 as well as provide some really cool new requested
> functionality.
>
> I'd very much appreciate any thoughts/comments/suggestions about this.
>
> TIA!!  =:)

Basically... at some point in the near future you will be asked if you want to 
release your application with KDE4.0.  If the answer is "no", then the Release 
Team will have to think of some way to manage the situation.

IMO: if your application is missing big feature chunks, as you describe above, 
then you shouldn't release.   The average run-of-the-mill bugs and regressions 
shouldn't be cause for un-releasabiltiy.

-Allen


_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/