http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167
--- Comment #79 from Paul Poulain <[email protected]> --- (In reply to comment #77) > (In reply to comment #76) > > question : if you're in user mode, it means you're running a published > > version right ? So there should not be any unnumbered dbrev ? > > conclusion = isn't the current behaviour correct ? > Update should only list/execute the unnumbered ones. You could have a > published version plus some custom work. You install that in dev mode and > then put Koha back to user mode. I guess that means that you normally should > not have unexecuted unnumbered dbrevs.. I feel we're misunderstanding ourselves: * if you're on a production server, you've only numbered DBrevs + your own local revisions (that can be numbered -bad idea- or no) * if you're on a test/dev server, you've numbered DBrevs (pushed already), plus unnumbered DBrevs that comes from patches you want to test. It's not related to being in dev mode or no. The dev mode just let you choose DBrevs one by one, where the normal mode apply everything, and that's all. > > Couldn't we also decide that 3.8 DBrevs are made on the old > > updatedatabase.pl, DBrevs for 3.10 are in the new one ? > > So no need to backport this enhancement to 3.8. > Good for me. But this issue will come up again between 3.10 and 3.11. You > will have dbrevs in 3.10 folder; they are a subset of the 3.11 folder. that's not a problem = you'll have to apply all patches coming from any folder anyway, isn't it ? > New (minor) point: C4/Update/Database: New dependency introduced: Can't > locate > File/Find/Rule.pm in @INC. Do you really need this one? You only need to get > some file > names? Just use glob? jonathan says glob doesn't handle recursivity, so this package fit our needs better. Jonathan will submit a patch that : * check dbrev on check auth page * add the cookie to avoid duplicate login * delete 3.9 from old updatedatabase, to start from a clean situation = 3.9-10 => everything in a 3.9 directory. The workflow would then be = * if you submit a patch that update database and should be ported to 3.8 => use the "old" updatedatabase.pl script * if you submit a patch that update database and will be for 3.10 => use the new mechanism and provide a version/bug NNNN.sql file. The RM will take care of moving it to 3.9/dbrevnumber.sql when pushing -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
