New subject: [Bug 7167] updatedatabase improvements

5 Nov 2011

      http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167

             Bug #: 7167
           Summary: updatedatabase improvements
    Classification: Unclassified
 Change sponsored?: ---
           Product: Koha
           Version: master
          Platform: All
        OS/Version: All
            Status: ASSIGNED
          Severity: enhancement
          Priority: P5
         Component: Architecture, internals, and plumbing
        AssignedTo: paul.poulain@biblibre.com
        ReportedBy: paul.poulain@biblibre.com
         QAContact: ian.walls@bywatersolutions.com

During the hackfest in Mumbaï, 5 of us had a brainstorming about
database changes to try to improve it.
Here are the goals:
* must result in patches being easier to test by testers (to sign-off)
* must result in less conflict when trying to apply a patch with a DB
update when another patch has been applied (the .XXXX problem)
* must fix the linear problem (where patches are applied in a completly
linear way)
* be easy to implement

We throwed many ideas, here is the one that seems both easy and usefull :
* patches would be submitted in a specific file, in atomicupdate directory
* a new file (YAML) would be added, that would have 2 columns, one for
the version number, one for the atomicupdate file name
* updatedatabase wouldn't change anymore: we would just add something like :
LoadYAMLFile()
ForEachLine {
    if (C4::Context->preference("Version") < FirstColumnYAML) {
        exec(secondColumnYAML);
        SetVersion (FirstColumnYAML);
    }
}
The YAML file would be updated only by the Release Manager, when he
pushes a patch.

This idea fully achieve most of our initial goals:
* (very) easy to implement
* it will be easier to test a patch : is there an atomic update in the
patch ? OK, to test it, i'll first execute the file
* there won't be any conflict anymore of a patch applied and your .XXXX
file not applying anymore, needing a rebase
* it fixes partially the linear problem = if you have a local branch,
you can see what has been applied just looking in the yaml file.
Let's say Limoges library has sponsored stuff that has resulted in
atomicupdate/limogeupdate.pl
Those changes are live in Limoges, but still not in official/community
version.
The Limoges YAML file will be:
3.07.0001 Community_change1.pl
3.07.0002 community_change2.pl
localchange limogesupdate.pl
3.07.0003 community_change3.pl
the "localchange" in first column will mean for the updater : "OK, apply
the change but don't change the version number"

When the localchange has been applied on master community branch, the
official/community YAML file will look like:
3.07.0001 Community_change1.pl
3.07.0002 community_change2.pl
3.07.0003 community_change3.pl
3.07.0004 limogesupdate.pl

Switching back limoges to a community version would require some manual
checking, but that will be *much* easier than what we have today :
* diff limoges.yaml official.yaml
* apply community changes if/where needed
* UPDATE systempreferences SET kohaversion=3.07.0004 manually
It's done !

And if the localchange that has been made is never merged into master,
whatever the reason, it will be easier to keep track of it too.

And if you want to apply a submitted patch to your local setup before
it's pushed onto master, you can, just by running the file in
atomicupdate directory. And add a "localchange" line to your YAML file
to remember the change you've made.

-- 
Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

[Bug 7167] New: updatedatabase improvements