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 ?