Michael Hafen a écrit : >>> 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. >>> I agree. But they already are. When one works on new features for 3.4 (see RFC for 3.4) and have to plan for DB updates, how does one deal with update database and rebase and merging ?
On the other hand, I agree I proposed things that could become very complicated. But it was brain dumping and proposals. I donot think the wiki has been much helpfull. It is quite difficult to plan how many updates you will need in order to bug fix and design a feature. It could be in fact a simple text file in installer/data/mysql/ ticketsclaim.... But then, simply getting But the fact is that it would not adress the fact that you can run multiple branches on the same codebase. And you would LOVE the merge to be the more seamless as possible. As release maintainer for 3.0 I **had to*** create and arrange db updates in a different order than master branch. Knowing wich db version you were on 3.00.01 and not 3.01 was really important, even though its management could have been improved. (Things that would add some tables and maybe break features should never have mixed up with stable code.) It ended up to be VERY tricky and dangerous to only cherry pick bug fixes unless master code is really close to maintenance branch. This lead to duplication of code. This would have been avoided if updatedatabase30.pl replaced updatedatabase.pl. But then, I would have had to cope with conflict at each cherry pick even if the commit would not update updatedatabase.pl. Not to mention all the db changes that local users may want to do and track. >> 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. > _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
