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@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@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@bywatersolutions.com Twitter: @sekjal