[Kolab-devel] IMAP resource, Kolab resource and the merged one
adam at kde.org
Tue Jan 18 18:22:55 CET 2005
On Friday 07 January 2005 19:06, Bernhard Reiter wrote:
> I still would like a way to completely switch off old style Kolab1
> storage in a set of binaries, but if I understand you correctly,
> this is technically not a nice solution because the code is so close
> to each other.
> We need to think about an upgrade path to future KDE releases
> that have a full client compatibility.
> The question would be if there is another way to make that switch,
> e.g. if on an upgrade the new Kontact would just switch those resources
> or run a tool for this.
After some long and hard thinking and several discussions with Bernhard and
David, I think the following would be best:
- disable the IMAP resource in proko2 completely, since it is broken
- only ship the kolab resource currently in proko2, which can only do
XML/Kolab2 type storage
- remove the storage type switch from proko2 KMail
- ship the merged resource in HEAD with KDE 3.4 under the type (internal name
used for discovery) IMAP, which means people upgrading 3.3 => 3.4 don't need
to do anything, since it replaces the one in 3.3
- ship an upgrade script with KDE 3.4 which renames any resources of type
"kolab" (as used by proko2 branch), to "imap". Note that this means types,
not user visible names, that's a whole different story. With this migration
proko2 => KDE 3.4 should be painless as well
- tell kroupware users to upgrade to 3.4, if they want the new features,
migration is again seemless here, since there it was also the type "imap"
Upsides: seemless migration for everyone, happiness and joy
Downsides: no ical/vcard support in proko2 branch at all, not even with
KDE 3.4 will be missing one feature, distribution list storage in contact
folders, which will make it only an almost complete Kolab2 client. I expect
there to be a patch set or branch against 3.4 which makes it possible to
build packages which produce a complete Kolab2 client, but I don't think that
that distinction is of much concern wrt the question of how to treat the
resources in the different branches.
If no one objects to this scheme, I will make it so soonish.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the devel