[Koha-devel] Bug 6328 (fine in days) and updatedatabase

[Ian Walls]

I'm with Chris N that a proof-of-concept test for this change would be
required first, before we switch over our entire process.  What we have
works, just not as well as our new method could.

I think that when the decision is made to implement this, we switch to it
completely.  Ideally, I'd like to see 3.6.0 as the cut-off, since that's
when both a stable release branch and master coinicided.  3.4.x is nearing
end of life, and I don't see too much difficulty in continuing to apply
database changes the old way to that branch.  But if we could just move on
from both master and 3.6.0 using the new method, we'd be able to reap more
of it's benefits.

If we cannot get this tested and ready in short order, it may be necessary
to postpone until 3.8.  As said, this is completely transparent to the end
user, so we're not delaying any useful features by being cautious.  And,
given this will change how developers do their coding, it'd be nice to give
enough time so that everyone can be trained up on the new method, so the QA
team doesn't have to do too much rejection or reformatting of perfectly
functional patches.

Cheers,


-Ian

On Thu, Nov 24, 2011 at 3:08 AM, Marcel de Rooy <M.de.Rooy at rijksmuseum.nl>wrote:

> > I explain again my idea:
> > * a patch related to a bug, that would end in 3.6.x, will require a
> > installer/data/mysql/updatedatabase patch, as previously (no change here)
> > * a patch related to an improvement, that will be released in 3.8 will
> > require a admin>updatedd patch, the new mechanism.
> >
> > It means there is no need to have 2 versions of the DB update. The
> > version needed is defined by the version where it will appear:
> > * if it's a bugfix => 3.6 => old mechanism
> > * if it's an ENH => 3.8 => new mechanism
>
> Would that bugfix not be included in 3.8 too? So you do need two versions?
>
>
> > == Someone run git.koha-community.org/master ==
> > Problem =
> > on Day 1, someone is running 3.06.00.001, it's OK.
> > on Day 2, the install says "version is 3.07.00.001", it's still OK
> > on Day 3, the "old" updatedatabase will say "3.06.00.002 already
> > applied, nothing to do" (because the number is set to 3.07, that is
> > bigger than 3.06 !)
> > => BUG, the 3.06.00.002 won't be applied and someone will face a problem
> !!!
> >
> > As i've been told that bywater customers are running master, we must
> > deal with this case.
> >
> > I had a discussion with Jonathan (joubu), that made the work at
> > BibLibre, he had a great and easy-to-do idea.
> > The idea would be:
> > * don't change the "version" systempreference on the new system for
> > instance. In about.pl, we still would see 3.06.01.002 (in my example)
> > * Just before releasing 3.8, reintroduce version increase, to have
> > "3.08.00.001" displayed in about.pl
> >
> > That would change nothing for ppl using only released versions, and
> > would work well for ppl running master !
>
> I would not like the idea of postponing version number increase. If we use
> a hash function for checking the version, we could catch this situation ?
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20111124/8b792302/attachment.htm>