[Koha-devel] How about a different way of handling database updates

[Michael Hafen]

> > My opinion is that the current system is not that bad. The
dependency
> > graph is linear, date ordered by version number last digits. It just
> > becomes crazy when updates are ported from one branch to the other, HEAD
> > to maintenance for example. And there is (am I wrong?) to claim
> > 'communitly' such a number:
> 
> The problem with the wiki page for db number claiming is it doesn't
> seem to work, at least it hasn't worked for me in the past. It assumes
> that the features will be committed in the order that the db numbers
> are claimed, which I don't believe is true. In that case, if the wiki
> page were enforced, then db versions would be committed out of order,
> and the updater would not work correctly. I just don't believe the
> wiki page is effective at all. After having a number of db version
> numbers stepped on, I stopped using it.
> 

This is one of the two major concerns I have with the current system,
and lead to my proposal.  The other concern is proprietary database
updates, which are practically impossible with the current system
because of this same problem of stomping on revision numbers.

On Fri, 2010-01-29 at 13:58 +0100, Paul Poulain wrote: 
> Frederic Demians a écrit :
> > Those kind of things can be tricky and messy. 
> Other idea : shouldn't we open a new position, named "database 
> consistency manager" or something like that ?

I don't think having a DB Consistency Manager is going to help that
much.  I don't think it would be much different from the wiki page.  It
would be one person in charge instead of several people trying to
coordinate.  But that person would still have a lot of work to do with
changing patches or making patches of their own to keep database updates
sane.



-- 
Michael Hafen
Systems Analyst and Programmer
Washington County School District
Utah, USA

for Koha checkout
http://development.washk12.org/gitweb/
or
git://development.washk12.org/koha