[Kolab-devel] IMAP resource, Kolab resource and the merged one

[Till Adam]

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.

[snip]

> 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 
           additional work

Note: 

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.

Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050118/9bce91c9/attachment.sig>