On 4/07/2007, at 12:54 PM, MJ Ray wrote:
"Joshua M. Ferraro" <jmf@liblime.com> wrote: [...]
I'd also like to point out that updatedatabase should start completely blank for 3.0. IMO updatedatabase shouldn't be the upgrade path from 1.x or 2.x to 3.0 ... rather, it should be the upgrade path for 3.0 to 3.2, etc. Other thoughts?
I thought updatedatabase started as the upgrade path from 2.0 to 2.2 or similar. How will 2.2 users upgrade to 3.0 if not updatedatabase?
Hmm yeah, good question.
I'd like to get feedback from everyone on the best way to maintain kohastructure.sql and updatedatabase, to make sure we always have a known SQL definition and update process. Comments, ideas?
Firstly, the dumps should be made with the same options. How about: LANG=C mysqldump -cnQ koha >kohastructure.sql ?
I like it
My second suggestion is more radical: kohastructure.sql should only be changed in a branch by the release manager. Ideally, that would only happen with each release at most. At all other times, ALTER statements and other transformations should be added to an upgrade file, say called kohastructure-3.0.0.sql, then kohastructure-3.0.1.sql - or should it be .pl and done with DBI commands?
If included in the release, they could also be the basis of the database upgrade, just running that one change file for each release.
That sounds like a great idea, much easier to track changes, and it does allow an easy upgrade path. Chris -- Chris Cormack chris.cormack@liblime.com VP Research and Development www.liblime.com LibLime +64 21 542 131