[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Koha-devel] Version numbering & updating
From: |
Paul POULAIN |
Subject: |
Re: [Koha-devel] Version numbering & updating |
Date: |
Thu, 16 Aug 2007 12:38:19 +0200 |
User-agent: |
Thunderbird 2.0.0.4 (X11/20070620) |
Paul POULAIN a écrit :
MJ Ray a écrit :
Sorry for any confusion: I meant having more than one point, so
N.S.T.V would still allow 4 numbers, but be Perl-style.
Hope that explains,
ah, OK. No problem for me with N.SS.TT.VVV ;-)
OK, it's commited in git. Waiting for libLime validation.
Here is my commit note, with an *important note added*, go to the end
directly if you've already read the commit
The kohaversion is in the code directory (in /kohaversion.pl)
C4::Context now has a new method C4::Context->KOHAVERSION
that returns the koha code version.
The systempreference Version contains the database version.
If the 2 are differents, when the user log in, he is redirected to web
installer (new behaviour : before this commit, the check was done on
everypage, it's too CPU costly I think)
In the web installer, we check now if we do a new setup or an upgrade
and show only the appropriate link.
The updatedatabase contains a lot of new things :
* SetVersion($kohaversion), that set the kohaversion after each update
* TransformToNum($kohaversion) that returns a number (3.0000001 from
3.00.00.001 for example) for a given koha version
* DropAllForeignKeys($table) that does what is written : drop all
foreign keys. A shame it's not possible directly in mySQL...
* for each database update, just :
add the following lines :
=item
Describe what it does for other developpers
=cut
$DBversion = "your.koha.version.dbnumber";
if (C4::Context->preference("Version") < TransformToNum($DBversion)) {
#
# DO YOUR UPDATE STUFF
#
print "Upgrade to $DBversion done (specify what it does if you
want)\n";
SetVersion ($DBversion);
}
IMPORTANT NOTES :
==== 1 ====
in koha 2.2, a new install was done through installing a 2.2.0 database,
then updating it to the installed version.
in Koha 3.0, /installer/kohaversion.sql MUST contain an uptodate
version, as the installer set the DB version to kohaversion after
uploading kohaversion.sql. It does NOT run updatedatabase.
==== 2 ====
The update from Koha 2.2 to Koha 3.0 must NOT be done through the
webinstaller : updatedatabase is very very long to run and you'll reach
Apache timeout for sure. See http://wiki.koha.org/doku.php?id=22_to_30
that contains my notes for upgrading (with some/few UNIMARC specific stuff)
==== 3 ====
(This note was not in my commit)
On a fresh install, you'll get an internal server error if you try to
load mainpage.
It's due to the fact that the database is empty, and I have moved the
webinstaller redirection AFTER the auth process.
Previously : the webinstall needed checking was done on every page
served, it's a big CPU consuming
Now : the webinstall needed checking is done only when the user is not
authenticated. It's less cpu consuming, but you need to write the
installer url specifically for a new install. I don't think it's a real
trouble (just say in the release notes / doc : after the tech install,
enter "http://your.webserver.com/cgi-bin/koha/installer/install.pl" to
do the database setup), and it's worth the cpu gain.
If you disagree, argue, it need 1mn to rollback (just move the 5 lines
checking the webinstall needed up)
--
Paul POULAIN et Henri Damien LAURENT
Consultants indépendants en logiciels libres et bibliothéconomie
(http://www.koha-fr.org)
Tel : 04 91 31 45 19