Hi Ralf, Peter.
The releasenotes (www.egroupware.org/wiki/releasenotes1.4) contain a
link describing the changes in addressbook
(www.egroupware.org/wiki/AddresbookAccountsConcept) which contains at
the end a link describing how to Update an LDAP based addressbook
(www.egroupware.org/egroupware/index.php?menuaction=phpbrain.uikb.view_ar
ti cle&art_id=57).
Ah. I did overlook that. I wrote a small perl-script to fetch the entries from
LDAP and put them into SQL. I guess it depends on the number of Categories,
which method is more work.
As LDAP is used by quite a small percentage of our users (with usually a
high sysadmin skill level), we choose to not provide a more automatized
procedure for the upgrade.
Still, from earlier releases an admin expects to just click “Update” in Setup
after a Version-Upgrade. Of course I understand, why you thought your time
would better be invested elsewhere.
- Addressbook ACLs change meaning without notice, meaning people won’t
be able to read what they used to be able to.
This might be an other documentation issue
Absolutely. Ideally, in such cases, Setup would provide the admin with Options
during the “update” process and act based on his decision. But at least it
needs to be documented.
- Shared folders no longer work with Felamimail and Courier IMAP.
Unfortunately the FMail developer abandoned the current FMail codebase
and noone else fixed that bug so far, thought I’m not even sure there’s
a bug report for it in the projects bug tracker.
I have fixed this one in a very rough way in IMAPProtocol.php in our
installation, but did not commit it, because it’s almost certainly going to
break different imap setups. Unfortunately, Lars did not respond when I asked
him to comment on the patch and a better location to fix this, but above
sentence seems to explain this.
- icalsrv is completely broken.
Really. You are talking about 1.4.002? Many people reported it working
better then ever (specially with Lightning/Sunbird) in 1.4.002. There
was a bug with one of the other iCal clients with the content-type,
which was fixed after 1.4.002 in svn and which will be included in the
next maintainance release 1.4.003
Calender works more or less the same as in 1.2 with IcalSrv, I guess (Using
korganizer as client). The problem was infolog (something about uid
translation). I needed to take patches from trunk/1.5 including a
schema-change, to make it work again. Those patches came from you, Ralf, so I
guess you know better than I, what I’m talking about. 
Of course, icalsrv
should not have been included in the 1.2 debian packages, as it’s stated in
icalsrv.php, that it’s experimental. Unfortunately, icalsrv.php was part of
the stable release tarballs, which led to the wrong conclusions, I guess.
The thing is, we are talking about the debian package here. Debian users
certainly are used to a minimum of manual work after a package upgrade. Of
course there are counter-examples (almost always web-apps), but I don’t think
it’s acceptable to have the user fetch the solutions to a handfull of issues
from a mixture of mailinglists, wikis, knowledgebasses, etc.
I guess usually in the case of difficult upgrades, the new packages would be
called app*-version (egroupware*-14) and contain a doc/README.upgrade to
avoid accidental upgrades with unprepared users. Of course this has the
disadvantage, that the old 1.2 packages are kept for a longer time without
upstream support.
Carsten
