[Kde-imaging] Digikam + Kipi + Export and/or Sync to web services (and other such stuff)

[Gilles Caulier]

2008/10/29 Angelo Naselli <anaselli at linux.it>

> martedì 28 ottobre 2008 alle 21:09, Colin Guthrie ha scritto:
> > There is definitely (IMO) scope for rebasing the whole KIPI API on top
> > of Akonadi but this is perhaps something that is best left for a future
> > occasion. Perhaps not, as I know the API breakage is up for discussion,
> > but I don't want to bite of more than can be comfortably chewed at the
> > moment!
> >
> There's no big problems in breaking on trunk, untill kde 4.2 freeze time.
> The discussion about api/abi breakage i'd like to have during kde code
> sprint concerns on the stable branch and during beta/rc phase, having
> attention to stable distros, e.g. the ones who want to use our packages.
>
> I mean i don't like to think we have to implement every time new
> functionalities during beta/rc, i'd expect more to stabilize the code
> instead.
> Moreover we can't base our work always on trunk, as far as our final
> product
> concerns. Maybe I'm wrong, but i can see the mess digikam does on mandriva
> 2009.0.


as i have already said, digiKam 0.10.0 is currently in beta release and not
stable. it's stupid to include it in Mandriva as official and stable version
because it must not be used in production. I specify this point in release
announce.

We have released a stable version for KDE3 : 0.9.4. this one must be used in
production. I don't know why Mandriva force use to use unstable version of
program, especially with digiKam. KDe3 version can be used without problem
under KDE4. There are some others KDE3 programs installed in Mandriva 2009.0
under KDE4 desktop as K3b or konversation. Why not digiKam ?

Also, if you want to unbreak binary compatibility with current
kdegraphics/libs installed by default from KDE 4.1.2 under Mandriva and use
digiKam from trunk using kdegraphics/libs from trunk, just install these
component un a dedicated place as /usr/local, and pass this path to digiKam
cmake configuration...

Best

Gilles Caulier





> It is almost unusable and to get new betas we need to backport
> things from kdegraphics trunk, that's ok for developers not for final
> users.
> So more attention to stable distros should be taken IMHO.
> I don't mean we don't have to add new features of course, but maybe we
> should work on branches once we have a beta out, and going on trunk for
> future releases. Of course it's a nonsense (always imo) releasing a new
> stable
> based on kdegraphics trunk since it has not been released yet....
>
> My 2€ cents.
>         Angelo
>
>
> _______________________________________________
> Kde-imaging mailing list
> Kde-imaging at kde.org
> https://mail.kde.org/mailman/listinfo/kde-imaging
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-imaging/attachments/20081029/3cd065e0/attachment.htm