Great, thank you.

Ok, I'll see if I can muster up some more energy to add something 
useful to the wiki. Seems like a good place for it indeed.



In retrospect I should have reported or at least recorded all the 
problems I had with the various upgrade scripts etc. as I was using 
them. I have mentioned the main issues (that I had recorded) briefly 
before by the way. But to be honest I didn't feel like spending a lot 
of energy on reporting and trying to understand why things were 
missing or not working as time was already in short supply for me and 
what little was there seemed to be somewhat haphazardly thrown 
together anyhow.



Right now, I'd rather work on improving things for current or future 
versions of Horde so I'm moving over to the mailing lists for further 
discussion.

The wiki (http://wiki.horde.org/) is a good place for user contributions.



I still don't know what specific problems you have with the upgrades. 
There are docs/UPGRADING files in all of our applications, along with 
scripts. It's tough to improve them if we don't know what problems 
people are having.

3.1.3 is the latest release for Debian stable (they backport security 
fixes) so it's still in common use and will be for a while to come.



My basic idea was to share these scripts some place where other admins 
looking to upgrade might find them and see if they were any use to 
them. I understand and am sorry for your frustration, but I think you 
will understand my frustration of not finding a clear data upgrade 
path as well. So after my research I just wanted to get things done 
and started hacking instead.



Anyhow, if there is no place for user contributions like these and 
seeing as they are out of line with the central design and philosophy 
I suppose they can just be left here. I already had my doubts whether 
these would be of any use to anybody, but I figured I should at least 
try to see if there was any interest.



I do have some more questions and ideas so I'll see you again on the 
mailing lists.

So, given that these are for Horde 3.1.3, which isn't even the latest 
stable release, and we are currently at RC-2 for Horde 3.2.0, and 
3.1.x is therefore only maintained for security fixes, what do you see 
us doing with these?



I very much appreciate your contributing what you have, but it's 
frustrating to get workarounds for bugs in old versions, instead of 
direct bug reports that might (or might not) still be relevant.



Any work you'd like to contribute on migrations or similar 
functionality would be quite welcome. If you are interested in it 
being included in the mainline distribution, however, I encourage you 
to ask questions on the dev list (http://horde.org/mail/) instead of 
working around APIs that aren't clear. The docs are certainly an 
issue, but we're friendly an answer questions.



A final note - the reason Horde's upgrade scripts avoid direct 
database access when possible is that allowing non-SQL drivers is 
central to Horde's design and philosophy. So scripts that ignore other 
backends are not likely to be featured in the core.

This is a collection of horde upgrade scripts I made to upgrade from a 
customized CVS checkout of Horde 3.0 to the current debian horde 
version 3.1.3.



I'm afraid these aren't ready to be included in the scripts directory 
straight away, but I feel they can be interesting to other people 
working on upgrading Horde. Perhaps they can be included in a contrib 
directory or something?



Some notes:

* Sorry, these scripts were meant for one time use so their not 
superbly engineered or commented.

* Contrary to most other scripts these don't depend on Horde being 
installed on the localhost, they only need a connection to Horde's 
database.

* copy_and_adapt_horde_3.0_to_3.1.sh is the base script which calls 
the other scripts to help copy and adapt the 3.0 database to a new 3.1 
database for use by the new installation of Horde

* move_history_from_datatree.php is the only script which is not 
customized at all to our particular installation, but the other files 
can be easily adapted to your situation.

* A few files have been stripped of some of the information for 
privacy reasons



Answers to some questions bound to be asked:

* Why didn't you just use the Horde API?

I couldn't find good documentation of the Horde API and found it 
easier to just reverse engineer its database usage. Furthermore I 
wanted to execute the scripts from another host for practical reasons.

* Why didn't you just use the existing upgrade scripts?

Database data model changes weren't properly reflected in the SQL 
upgrade scripts.

move_history_out_of_datatree.php was extremely slow and didn't work 
properly (I could not find back some email history entries).

migrate_user_categories.php didn't convert numeric category values to 
the new text category name values.

public_to_horde_share.php didn't work for me (sorry, forgot why exactly).





PS: I can't wait for automatic upgrade functionality in Horde. At the 
very least any data model changes should be automatically handled IMHO.