[Koha-devel] patches with DB change, workflow

[LAURENT Henri-Damien]

Le 23/05/2011 14:48, Chris Nighswonger a écrit :
> Hi Paul,
> 
> On Mon, May 23, 2011 at 8:17 AM, Paul Poulain <paul.poulain at biblibre.com
> <mailto:paul.poulain at biblibre.com>> wrote:
> 
>     Hi all,
> 
>     I think there are some things unclear (at least for me ;-) ) about
>     submitting bugs with DB changes.
> 
> 
> <snip>
>  
> 
>     * we spoke of using XXXX in updatedatabase.pl
>     <http://updatedatabase.pl> to have te RM pick the
>     right number when needed.
> 
> 
> 
> Speaking from the prospective of Release Maintainer, this method works
> the most consistent for me. I have very few times when a DB update patch
> using the 3.NN.XXX format does not apply cleanly for me. This includes
> cases where NN == some subversion other than the current maintenance
> version. So with this, my workflow goes like this:
> 
> 1. Apply patch/cherry pick.
> 2. Adjust rev number.
> 3. Commit rev number change.
> 4. Go on to the next patch.
> 
> On the rare occasion the original patch does not apply cleanly it takes
> all of about one minute to fixup.
> 
> So my vote is to use this method unless there is a very compelling
> reason to do otherwise.
OK.

When you have something that should apply both to 3.2 and 3.4 (say an
index change, or a change on a field (text to varchar or varchar to text
or varchar 10 to varchar 255), you number that from which number ?) Do
you keep the least number or do you use two different rev numbers ?
If you keep both, when upgrading, you will have some unwanted issue raised.
If you take the least, then the number of the revision in the master
branch is not the correct one, and when ppl upgrade they either will
loose some db changes or have duplicate numbers.
It can be solved with a kind of "deduplication table".
But rather uneasy to implement.
Could be also solved with a variable that says... ok if you come from
3.2 then it is that number, 3.4 that other... But upgrade path will have
to decide which path you are coming from.

I don't have THE solution.

I mean I had the problem with 3.0 to 3.2 and the "best way" (in terms of
time/development/tests) to cope with it was to store the initial
kohaversion and make a test. (see MT2308b on our git.)

Keep up the good job Chris.

But this is an old issue, and some points were made back in 2010 in a
thread named How about a different way of handling database updates
http://www.mail-archive.com/koha-devel@lists.koha.org/msg03423.html

Problem with patches and contributions more and more numerous will raise
that again.

My 2 cents.
-- 
Henri-Damien LAURENT