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

[Marcel de Rooy]

> 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 ?