There is one great advantage of the current approach, and that is that when a user says "we are on Koha version X", you know exactly what the database state for that should be. You know the tables, fields, constraints AND the codebase. To be clear, that means that you can *do development* specified against that version number.
Similarly, the RM only has to know that the next increment applies cleanly to previous one. He does not have to go hunting down edge cases where DB-thread X and public-proprietary-thread Y conflict in the absence of some random other thread Z. I would advise that we should not relinquish this advantage without serious consideration. Once you get into mix/match situation, the version number does NOT tell you the state of the database. The way LibLime handled LEK updates was quite simple. They had a different syspref declaring the internal version number. They batched all the internal updates in a chunk at the end of the main updatedatabase body, using the same kind of logic. You should be able to find a commit by Ryan where he adds some whitespace to updatedatabase to make it even easier to delineate. I suggest if you want to pursue it, that reimplementing that with say LocalCustomVersion would be the simplest approach. When the customizer is ready to commit back to mainline, she can combine all the local DB updates into one current KohaVersion update. For comparison, let me mention DB updates for Evergreen. Only after I started working on it did Evergreen adopt any explicit DB versioning! That has been resolved using a script that processes individual incremental SQL files: http://svn.open-ils.org/trac/ILS/browser/trunk/Open-ILS/src/sql/Pg/upgrade That system is pretty good. However with multiple committers, the "I got next" linearity is still a small problem. So in the end, I think that is just the price you pay for having the version number refer to a known DB state. --Joe Atzberger
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
