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

[Paul Poulain]

Le 23/11/2011 16:23, Chris Nighswonger a écrit :
> On Wed, Nov 23, 2011 at 10:04 AM, Paul Poulain
> <paul.poulain at biblibre.com> 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