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 _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
