> 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 [email protected] 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/
