Le 23/11/2011 16:23, Chris Nighswonger a écrit : > On Wed, Nov 23, 2011 at 10:04 AM, Paul Poulain > <[email protected]> wrote: >> 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: > > So why is moving 3.6.x to the new updatedatabase code not a good idea? > It presents a rather simple solution to all of the 3.6.x maintenance > issues and even migration issues at this point. What am I missing?
We had a long discussion about this on IRC (kf, jcamins, chris_n & me) I explain again my idea: * a patch related to a bug, that would end in 3.6.x, will require a installer/data/mysql/updatedatabase patch, as previously (no change here) * a patch related to an improvement, that will be released in 3.8 will require a admin>updatedd patch, the new mechanism. It means there is no need to have 2 versions of the DB update. The version needed is defined by the version where it will appear: * if it's a bugfix => 3.6 => old mechanism * if it's an ENH => 3.8 => new mechanism BUT: It seems there is a case i had forgotten: people running master (bywater, hello ;-) ) Tests cases: Day 1 : version= 3.06.00.001 has been released D2 : patch pushed, with new update system, version=3.07.00.001 Will be released officially in 3.8.0 D2 : patch pushed, it's a bug, so cope with old updatedatabase system, version=3.06.00.002. Released in 3.6.2 == Someone upgrade from 3.4 to 3.6.2 == No problem = the version is set to 3.06.00.002, and later upgrade to 3.8 will add 3.07.00.001 as well == Someone upgrade from 3.6.x to 3.8 == No problem = the upgrade use the new system, and upgrade to 3.07.00.001 == Someone upgrade from 3.4 to 3.8 == No problem = the upgrade will explain someone will have to run installer/data/mysql/updatedatabase (the old mechanism) THEN admin>updatedatabase (the new one) That was exactly how we did for 2.2 => 3.0 upgrade (see http://wiki.koha-community.org/wiki/Upgrading_2.2: > installer/data/mysql/update22to30.pl That will update the database to the 3.0 > structure. > Go and take a coffee, it can be long or very long, depending on your Database size. <snip> > installer/data/mysql/updatedatabase.pl this script will finish the update of > the database. == Someone install a fresh 3.8 == No problem = works without any specific update == Someone run git.koha-community.org/master == Problem = on Day 1, someone is running 3.06.00.001, it's OK. on Day 2, the install says "version is 3.07.00.001", it's still OK on Day 3, the "old" updatedatabase will say "3.06.00.002 already applied, nothing to do" (because the number is set to 3.07, that is bigger than 3.06 !) => BUG, the 3.06.00.002 won't be applied and someone will face a problem !!! As i've been told that bywater customers are running master, we must deal with this case. I had a discussion with Jonathan (joubu), that made the work at BibLibre, he had a great and easy-to-do idea. The idea would be: * don't change the "version" systempreference on the new system for instance. In about.pl, we still would see 3.06.01.002 (in my example) * Just before releasing 3.8, reintroduce version increase, to have "3.08.00.001" displayed in about.pl That would change nothing for ppl using only released versions, and would work well for ppl running master ! Is there still a case that would cause pain ? kf & others proposed an IRC meeting to discuss of this. Is it still needed ? -- 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/
