[Koha-devel] Bug 6328 (fine in days) and updatedatabase

Paul Poulain paul.poulain at biblibre.com
Wed Nov 23 16:04:03 CET 2011


Le 23/11/2011 15:27, Chris Nighswonger a écrit :

> I am a little confused. If you are suggesting that we back port the
> new updatedatabase scheme, I am in support of this.
Not at all ! I was suggesting to:
* keep actual updatedatabase as it is for 3.6
* have the new updatedatabase for 3.8
* for patches that require an updatedatabase in 3.6.x, we will need to
have :
 - the 3.6 updatedatabase (for ppl updating to 3.6.x)
 - the 3.8 updatedatabase (for ppl that, in the future will upgrade from
3.Y to 3.8 (Y<6) )

But, working more deeply on this, I think it's a *bad idea*.
My feeling here is that we will face a lot of pain to manage both 3.6=>
3.8 and 3.0 / 3.2 / 3.4 => 3.8, by trying to have 2 different
updatedatabase methods at the same time.

SO, maybe we should define as mandatory to migrate in 2 steps:
- from 3.0 / 3.2 / 3.4 to 3.6.x, (old method)
- then 3.6.x => 3.8 (new method)

That's what we did for migration from 2.2 to 3.0 = 1st, execute
updatedatabase22to30.pl (that was totally different from the 3.x
updatedatabase), then the new updatedatabase.pl

In this case, the 6328 patch can be applied on both branches (master and
3.6 The updatedatabase part of the 3.8 will be useless -as
updatedatabase will be deprecated in 3.8, in favour of the new
non-linear update system)

BUT for libraries migrating from a version before 3.6, the workflow
would be: updatedatabase.pl (the old one, renamed
updatedatabase30to36.pl maybe), THEN the new updatedb system.

Am I clear ? Do others understand and agree ?
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08


More information about the Koha-devel mailing list