Re: [Koha-devel] Bug 6328 (fine in days) and updatedatabase
Hi chris_n, The 6328 patch has been QAed by Ian, and can now be pushed. BUT there is a problem that i'll try to explain: * as i've announced in my Koha 3.8 release notes and we've worked during KohaCon11 Hackfest, we're working on a new method to update database on a non linear way. Jonathan has written code for that. It works pretty well, i'm testing and there is only (I think) a remaining problem for fresh installs I plan to work on today. Then i'll submit the patch (see bug 7167). * my plan, until this is ready, is to queue all patches that have a database update. Thus, 3.8 will only have the new method for update. * The problem is for bugfixes that have a DB update and must be in 3.6. There should be only a few of them, but here is the 1st, so, we must deal with it. My proposition: * you apply this patch on the 3.6.x * when the new method is ready, we rewritte the patch for 3.8 updatedb At the end: * fresh 3.8 will have directly the correct DB * 3.6.2+ will be updated to have the correct DB. When upgrading to 3.8, the new updater will have to check for this and not try to update the DB once again * 3.6.0 upgraded to 3.8 will be upgraded through the new DB update, that will handle this case. Is there something i'm missing ? Are you OK with this proposition ? -------- Message original -------- Sujet: Re: Bug 6328 (fine in days) and QA Date : Sat, 19 Nov 2011 10:08:36 -0500 De : Ian Walls <ian.walls@bywatersolutions.com> Pour : Paul Poulain <paul.poulain@biblibre.com> Passed, with a note about a small template change still required on circ/circulation.tt <http://circulation.tt> around line 390. Not worth holding up QA for this, though, as a followup patch could be very easily generated. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Hey Paul, On Wed, Nov 23, 2011 at 6:01 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
My proposition: * you apply this patch on the 3.6.x * when the new method is ready, we rewritte the patch for 3.8 updatedb
At the end: * fresh 3.8 will have directly the correct DB * 3.6.2+ will be updated to have the correct DB. When upgrading to 3.8, the new updater will have to check for this and not try to update the DB once again * 3.6.0 upgraded to 3.8 will be upgraded through the new DB update, that will handle this case.
Is there something i'm missing ? Are you OK with this proposition ?
I am a little confused. If you are suggesting that we back port the new updatedatabase scheme, I am in support of this. While this is technically an enhancement, it is not a "feature" in the proper sense. It is only a "feature" from a developer's prospective. Applying it to 3.6.x will keep a maintenance nightmare from occurring. The question regarding such a nightmare is not really "if" but "when." If the new updatedatabase code will be applied to master in the next week, I am inclined to wait to apply the fix for 6328. Since this touches template files and 3.6.x is presently in a string freeze, it will not make it into 3.6.1 any way, so the wait will not hurt. If the new updatedatabase code will *not* be applied in the next week, then as soon as the 3.6.x branch is thawed, I'll be glad to apply this patch. Feel free to set me straight if I'm not understanding your proposal. Kind Regards, Chris
Le 23/11/2011 15:27, Chris Nighswonger a écrit : > I am a little confused. If you are suggesting that we back port the > new updatedatabase scheme, I am in support of this. Not at all ! I was suggesting to: * keep actual updatedatabase as it is for 3.6 * have the new updatedatabase for 3.8 * for patches that require an updatedatabase in 3.6.x, we will need to have : - the 3.6 updatedatabase (for ppl updating to 3.6.x) - the 3.8 updatedatabase (for ppl that, in the future will upgrade from 3.Y to 3.8 (Y<6) ) But, working more deeply on this, I think it's a *bad idea*. My feeling here is that we will face a lot of pain to manage both 3.6=> 3.8 and 3.0 / 3.2 / 3.4 => 3.8, by trying to have 2 different updatedatabase methods at the same time. SO, maybe we should define as mandatory to migrate in 2 steps: - from 3.0 / 3.2 / 3.4 to 3.6.x, (old method) - then 3.6.x => 3.8 (new method) That's what we did for migration from 2.2 to 3.0 = 1st, execute updatedatabase22to30.pl (that was totally different from the 3.x updatedatabase), then the new updatedatabase.pl In this case, the 6328 patch can be applied on both branches (master and 3.6 The updatedatabase part of the 3.8 will be useless -as updatedatabase will be deprecated in 3.8, in favour of the new non-linear update system) BUT for libraries migrating from a version before 3.6, the workflow would be: updatedatabase.pl (the old one, renamed updatedatabase30to36.pl maybe), THEN the new updatedb system. Am I clear ? Do others understand and agree ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Wed, Nov 23, 2011 at 10:04 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Le 23/11/2011 15:27, Chris Nighswonger a écrit :
I am a little confused. If you are suggesting that we back port the new updatedatabase scheme, I am in support of this. Not at all ! I was suggesting to:
So why is moving 3.6.x to the new updatedatabase code not a good idea? It presents a rather simple solution to all of the 3.6.x maintenance issues and even migration issues at this point. What am I missing? Kind Regards, Chris
Le 23/11/2011 16:23, Chris Nighswonger a écrit :
On Wed, Nov 23, 2011 at 10:04 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Le 23/11/2011 15:27, Chris Nighswonger a écrit :
I am a little confused. If you are suggesting that we back port the new updatedatabase scheme, I am in support of this. Not at all ! I was suggesting to:
So why is moving 3.6.x to the new updatedatabase code not a good idea? It presents a rather simple solution to all of the 3.6.x maintenance issues and even migration issues at this point. What am I missing?
We had a long discussion about this on IRC (kf, jcamins, chris_n & me) 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 BUT: It seems there is a case i had forgotten: people running master (bywater, hello ;-) ) Tests cases: Day 1 : version= 3.06.00.001 has been released D2 : patch pushed, with new update system, version=3.07.00.001 Will be released officially in 3.8.0 D2 : patch pushed, it's a bug, so cope with old updatedatabase system, version=3.06.00.002. Released in 3.6.2 == Someone upgrade from 3.4 to 3.6.2 == No problem = the version is set to 3.06.00.002, and later upgrade to 3.8 will add 3.07.00.001 as well == Someone upgrade from 3.6.x to 3.8 == No problem = the upgrade use the new system, and upgrade to 3.07.00.001 == Someone upgrade from 3.4 to 3.8 == No problem = the upgrade will explain someone will have to run installer/data/mysql/updatedatabase (the old mechanism) THEN admin>updatedatabase (the new one) That was exactly how we did for 2.2 => 3.0 upgrade (see http://wiki.koha-community.org/wiki/Upgrading_2.2:
installer/data/mysql/update22to30.pl That will update the database to the 3.0 structure. Go and take a coffee, it can be long or very long, depending on your Database size. <snip> installer/data/mysql/updatedatabase.pl this script will finish the update of the database.
== Someone install a fresh 3.8 == No problem = works without any specific update == 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 ! Is there still a case that would cause pain ? kf & others proposed an IRC meeting to discuss of this. Is it still needed ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Wed, Nov 23, 2011 at 12:21 PM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Is there still a case that would cause pain ?
kf & others proposed an IRC meeting to discuss of this. Is it still needed ?
I would like to see us do something like this: 1. Publish a test branch which implements what Paul has described in full working form, including the ability to demo adding a db update to both 3.6.x and 3.7.x as proof-of-concept. Theory and explanations are nice, but a working demo is proof of the pudding (Englishism here). 2. Following this, we can conclude our list discussion and/or irc discussion, and go from there. This will also give us an opportunity to submit further improvements/enhancements/etc. which may arise out of testing the proof-of-concept. We can even set a time table for these things to happen. I see absolutely no reason to rush this sort of change. The system we have in place now *does* work. It may be a bit of a pain to some, but it has worked through at least three release cycles. The proposed change does not affect the user in any case. I realize that some may be already going a different direction internally with regard to db updates, while others may be relying on the master branch for production use. Each may choose his own poison in this regard, but rushing through changes which have global effects will surely lead to disastrous results. For the record: I am not particularly married to the existing updatedatabase.pl methodology. What I don't want is to see the current stable release laid to rest early. Assurances aside, I'd like to see proof-of-concept before withdrawing my objections. Kind Regards, Chris
On Wed, Nov 23, 2011 at 12:21 PM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Is there still a case that would cause pain ?
kf & others proposed an IRC meeting to discuss of this. Is it still needed ?
I would like to see us do something like this:
1. Publish a test branch which implements what Paul has described in full working form, including the ability to demo adding a db update to both 3.6.x and 3.7.x as proof-of-concept. Theory and explanations are nice, but a working demo is proof of the pudding (Englishism here). The patch attached on the bug are almost working. I'll update them, and
Le 23/11/2011 21:01, Chris Nighswonger a écrit : that will be easy to test.
2. Following this, we can conclude our list discussion and/or irc discussion, and go from there. This will also give us an opportunity to submit further improvements/enhancements/etc. which may arise out of testing the proof-of-concept.
Agreed.
I see absolutely no reason to rush this sort of change. My hurry was due to the fact I don't wanted to block bugfixes that have an impact on updatedatabase because of the new updatedb management system is not ready. But after all those discussions, I think the previous 3.6 will be OK even with the new 3.8 one. So I'll probably push those patches as they are (for both master & 3.6.x)
It may be a bit of a pain to some, but it has worked through at least three release cycles. The proposed change does not affect the user in any case. Yes it does: if a customer has sponsored a feature with DB changes, applying the patch to this customer before it's included in official version is a nightmare. And it appends more than once a year for BibLibre.
PS: as i've said on the other thread, i'll work on patches to have something ready to test, in a very close delay. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Thu, Nov 24, 2011 at 10:27 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Le 23/11/2011 21:01, Chris Nighswonger a écrit :
It may be a bit of a pain to some, but it has worked through at least three release cycles. The proposed change does not affect the user in any case. Yes it does: if a customer has sponsored a feature with DB changes, applying the patch to this customer before it's included in official version is a nightmare. And it appends more than once a year for BibLibre.
IMHO customers who want features before master inclusion is really a vendor issue, not a community issue. Yes, we want to make changes that will make life easier on vendors (and therefore their customers), *but* not at the expense of rushing and possibly introducing a potentially buggy, not-throughly-tested "enhancement." Don't interpret this as "anti-vendor," rather as "pro-stability." ;-) Kind Regards, Chris
On Thu, Nov 24, 2011 at 11:02 AM, Chris Nighswonger < cnighswonger@foundations.edu> wrote:
On Thu, Nov 24, 2011 at 10:27 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Yes it does: if a customer has sponsored a feature with DB changes, applying the patch to this customer before it's included in official version is a nightmare. And it appends more than once a year for BibLibre.
IMHO customers who want features before master inclusion is really a vendor issue, not a community issue. Yes, we want to make changes that will make life easier on vendors (and therefore their customers), *but* not at the expense of rushing and possibly introducing a potentially buggy, not-throughly-tested "enhancement."
Agreed. While it's not ideal, having a separate script for non-community feature database changes isn't that difficult, if you need to do it a lot. And it's encouragement to make sure that all database changes are idempotent, which isn't a bad thing. I decided not to go that route, because any features of that complexity go to the community first. This way someone else tests them before they're deployed. But putting private updates in a different file is easily manageable, and greatly reduces merge conflicts. I don't remember exactly how I did it off the top of my head, but I think I just added an updatedatabase-cp.pl script which was run by the updatedatabase.pl script, when I was experimenting with applying database updates in advance of the features being committed. I did this way back, when I needed OpacPublic and we were still working on revising the patch for inclusion in Master. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
Le 24/11/2011 17:02, Chris Nighswonger a écrit : > On Thu, Nov 24, 2011 at 10:27 AM, Paul Poulain > IMHO customers who want features before master inclusion is really a > vendor issue, not a community issue. Chris_n, I disagree (strongly) with you here: according to me, anyone issue is important. We should not discard anything just because it's "a vendor issue". Well, at least when the ppl who had a problem comes with a patch! For example, Eliott' thread started a few hours ago is interesting: frankly, having pain merging the hourly loans patch is "a library issue, not a community ones". Well, in fact, I don't think so. Solving problems and making ppl happy is important. That's how we will attract more developers. 6 months ago, i've started a thread that explain this better than I do: http://www.codesimplicity.com/post/open-source-community-simplified/ Just the paragraphs headers: " Retaining Contributors * Respond to contributions immediately. * Be extremely kind and visibly appreciative. * Encourage a total absence of personal negativity. " In this specific case, bug 7167 is trying to solve a problem that has been discussed during hackfest, and ppl agree it is (a problem). So it's not a "vendor issue" only. The patch will: * ease developer work (ie: merge conflict removed) * ease RM work (ie: no number to assign when pushing). It also mean lower the risk of doing a mistake * simplify the code a little bit (ie: not checking on everypage that there is something to do, it's made just on mainpage.pl) * give more feedback (ie: DB changes are stored in the database. If there is a problem, you'll be able to know what happened. As a vendor, it's important: we can "prove" that a patch has been applied -or not- even 2 months after the update. That's a *big* improvement when you have 100+ Koha setups to manage !) I can also add "having a feature before official inclusion" is, in fact very good for the community ! I think there are some (few ?) libraries that could be happy to: * test a patch on their test server * if it works, apply it to production server * if things goes OK, "sign-off" the patch on bugzilla => patch is signed-off, it's good for the community. > Yes, we want to make changes that > will make life easier on vendors (and therefore their customers), > *but* not at the expense of rushing and possibly introducing a > potentially buggy, not-throughly-tested "enhancement." I don't understand why you say that. The patch is submitted, i've tested it heavily, I don't plan to push is without respecting the workflow, so there is no more risks than for any other patch ! What I agree with is that I won't let this bug be lost in the wild, as it's an important structural change I want to do first before pushing any important new feature. For version consistency, it's better. So, my proposal: stop feeding a possible troll, and go test my patch ;-) HTH -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Wed, Nov 30, 2011 at 12:50 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Le 24/11/2011 17:02, Chris Nighswonger a écrit :
On Thu, Nov 24, 2011 at 10:27 AM, Paul Poulain IMHO customers who want features before master inclusion is really a vendor issue, not a community issue. Chris_n, I disagree (strongly) with you here: according to me, anyone issue is important. We should not discard anything just because it's "a vendor issue". Well, at least when the ppl who had a problem comes with a patch!
I stand by my original statement. Issues which are fundamentally vendor/client are not and should not be the driving/motivating/controlling force behind the way the community moves. If this were the case, chaos would ensue as we change direction attempting to "fix" vendor/client issues, etc. I think you my be interpreting my statement as "anti-vendor." As I clearly stated: it is not. We do need to make adjustments to make the life of a vendor as easy as possible. But rushing a db update change because Biblibre, or any other vendor, has clients who run non-master modifications, is not at all a valid option. Having said that, if you have the proposed db update changes throughly tested, debugged, and production ready, then by all means, let's implement them in master. You will carefully recall my objections: 1. We should not introduce this "feature" without proof-of-concept *and* through testing. This "feature" over any other must be as stable as we can make it when it is introduced into master simply because instability could greatly slow down development. And while we are speaking of vendor/client relationships, imagine what problems ensue for vendors who have clients running over master when master breaks? Well, the vendor knows the risk and assumes liability for it in those cases, but you can see where we would be if we suddenly judged every move by vendor/client relationships. 2. If the db update improvements are introduced into master during the 3.7.x development cycle, they must be back ported to the 3.6.x branch. The only condition I will withdraw this objection under is if this "feature" is pushed immediately prior to the release of 3.8.0. I think that as a non-vendor, our views will always be in a tension. But that tension should be constructive in helping to maintain a proper balance in the best interest of the community.
For example, Eliott' thread started a few hours ago is interesting: frankly, having pain merging the hourly loans patch is "a library issue, not a community ones". Well, in fact, I don't think so. Solving problems and making ppl happy is important. That's how we will attract more developers.
It is a pain. And that pain may be getting to a sufficient level to motivate some to either test/sign-off/QA or to pay to have it done... problem solved. Until that pain reaches that level, it will continue to be a pain. Whatever one's viewpoint, In a majority rules context, the majority does not always move the direction of the individual. Under those rules, it is incumbent upon the individual to create a majority. No single vendor represents a majority. The rules for acceptance of a feature into master have been well defined at this point in our history. Sign-off, QA approval, and you're in. I'm not sure where hourly loans is hung up in this process, but I don't see why it has to be if someone wants to throw time or money at it. Kind Regards, Chris
Le 30/11/2011 15:54, Chris Nighswonger a écrit :
We do need to make adjustments to make the life of a vendor as easy as possible. OK, so we agree. I just want that ! (is my english saying something so different than this ?)
But rushing a db update change because Biblibre, or any other vendor, has clients who run non-master modifications, is not at all a valid option. agreed. And I don't want to rush pushing. I just rushed proposing something. Now, please test ! I want to do this quickly not because our customers are in a hurry, but because i'm starting pushing for 3.8 and I want to have a clean situation, not a mechanism that is the old one for the first 3 months, and the new one for the last 3 months.
Having said that, if you have the proposed db update changes throughly tested, debugged, and production ready, then by all means, let's implement them in master. OK, so, feel free to test !
You will carefully recall my objections:
1. We should not introduce this "feature" without proof-of-concept *and* through testing. This "feature" over any other must be as stable as we can make it when it is introduced into master simply because instability could greatly slow down development. agreed. And that's why we made so many tests (Jonathan and me) and took care of some problems that have been noticed. Now, I think I've submitted a patch that works quite well, with documentation. So please test & report any issue you could find !
And while we are speaking of vendor/client relationships, imagine what problems ensue for vendors who have clients running over master when master breaks? Well, the vendor knows the risk and assumes liability for it in those cases, but you can see where we would be if we suddenly judged every move by vendor/client relationships. agreed (even if we don't have any library running master)
2. If the db update improvements are introduced into master during the 3.7.x development cycle, they must be back ported to the 3.6.x branch. The only condition I will withdraw this objection under is if this "feature" is pushed immediately prior to the release of 3.8.0. I don't understand why we need to backport this new mechanism. With the new system, we can address separately updateDB patches for stable and master version (with the same patch, I don't mean in 2 different patches). I think that's how we must do it.
Let me give you an example with actual mechanism: Day 1 => updatedatabase for bugfix passes QA and can be pushed Day 2 => updatedatabase for a new feature passes QA and can be pushed Day 3 => updatedatabase for a bugfix passes QA and can be pushed How will you deal with D2 patch ? ATM, you'll have a problem, isn't it ? D1 = should be 3.07.00.001 on master D2 = should be 3.07.00.002 on master D3 = should be 3.07.00.003 on master except you're not supposed to push D2 patch on stable branch. (or there's something i'm missing)
I think that as a non-vendor, our views will always be in a tension. But that tension should be constructive in helping to maintain a proper balance in the best interest of the community. +1
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Wed, Nov 30, 2011 at 10:53 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Le 30/11/2011 15:54, Chris Nighswonger a écrit :
2. If the db update improvements are introduced into master during the 3.7.x development cycle, they must be back ported to the 3.6.x branch. The only condition I will withdraw this objection under is if this "feature" is pushed immediately prior to the release of 3.8.0. I don't understand why we need to backport this new mechanism. With the new system, we can address separately updateDB patches for stable and master version (with the same patch, I don't mean in 2 different patches). I think that's how we must do it.
Let me give you an example with actual mechanism: Day 1 => updatedatabase for bugfix passes QA and can be pushed Day 2 => updatedatabase for a new feature passes QA and can be pushed Day 3 => updatedatabase for a bugfix passes QA and can be pushed
How will you deal with D2 patch ? ATM, you'll have a problem, isn't it ? D1 = should be 3.07.00.001 on master D2 = should be 3.07.00.002 on master D3 = should be 3.07.00.003 on master except you're not supposed to push D2 patch on stable branch. (or there's something i'm missing)
I think you have missed something. Take a look at the release notes for 3.6.1. You will see several enhancement bugs included. These are smallish and are included because they improve existing features. This has been true from day one of my tenure as Release Maintainer. If you remove the ability to back port all enhancements, you remove this option. I maintain my opposition to not back-porting the db update changes. Kind Regards, Chris
As eager as I am to have a more robust database update method, I think the ship has sailed for 3.8. I believe the new mechanism should be part of both 3.6.x and master, so we're going to need a time when 3.6.x == master, at least on the DB level. That may or may not happen, as new features come along. The next time we know stable release and master will be equal is just after 3.8 releases. So, how about we test this new mechanism, but slate it for release along with 3.8? -Ian On Wed, Nov 30, 2011 at 10:58 AM, Chris Nighswonger < cnighswonger@foundations.edu> wrote:
On Wed, Nov 30, 2011 at 10:53 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Le 30/11/2011 15:54, Chris Nighswonger a écrit :
2. If the db update improvements are introduced into master during the 3.7.x development cycle, they must be back ported to the 3.6.x branch. The only condition I will withdraw this objection under is if this "feature" is pushed immediately prior to the release of 3.8.0. I don't understand why we need to backport this new mechanism. With the new system, we can address separately updateDB patches for stable and master version (with the same patch, I don't mean in 2 different patches). I think that's how we must do it.
Let me give you an example with actual mechanism: Day 1 => updatedatabase for bugfix passes QA and can be pushed Day 2 => updatedatabase for a new feature passes QA and can be pushed Day 3 => updatedatabase for a bugfix passes QA and can be pushed
How will you deal with D2 patch ? ATM, you'll have a problem, isn't it ? D1 = should be 3.07.00.001 on master D2 = should be 3.07.00.002 on master D3 = should be 3.07.00.003 on master except you're not supposed to push D2 patch on stable branch. (or there's something i'm missing)
I think you have missed something. Take a look at the release notes for 3.6.1. You will see several enhancement bugs included. These are smallish and are included because they improve existing features. This has been true from day one of my tenure as Release Maintainer. If you remove the ability to back port all enhancements, you remove this option.
I maintain my opposition to not back-porting the db update changes.
Kind Regards, Chris _______________________________________________ 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
Le 30/11/2011 17:18, Ian Walls a écrit :
As eager as I am to have a more robust database update method, I think the ship has sailed for 3.8. I believe the new mechanism should be part of both 3.6.x and master, so we're going to need a time when 3.6.x == master, at least on the DB level. That may or may not happen, as new features come along. The next time we know stable release and master will be equal is just after 3.8 releases.
So, how about we test this new mechanism, but slate it for release along with 3.8? I don't see where/why the ship has sailed for 3.8. I have pushed only DB updates that are bugfixes, and would not be changed at all by the new system. I just refrain from pushing big ENH that would make the ship sail. And that's why I seem to be in a hurry: it's because I want to block as shortly as possible the ship!
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Le 30/11/2011 16:58, Chris Nighswonger a écrit :
I maintain my opposition to not back-porting the db update changes.
Just to be clear: I have no opposition to back-port this improvement. I just was not seeing why it would be necessary. Now I understand. And agree. And nothing must be changed on the new system, as it can handle every case (I think). -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Wed, Nov 30, 2011 at 11:34 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Le 30/11/2011 16:58, Chris Nighswonger a écrit :
I maintain my opposition to not back-porting the db update changes.
Just to be clear: I have no opposition to back-port this improvement. I just was not seeing why it would be necessary. Now I understand. And agree. And nothing must be changed on the new system, as it can handle every case (I think).
Ok, as soon as the necessary sign-off/QA is done, I have no objection to this being pushed up. We just need to act a soon as possible. I'll try to sign-off today or tomorrow, but it would be good for others to do so as well. Kind Regards, Chris
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 ?
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
participants (6)
-
Chris Nighswonger -
Chris Nighswonger -
Ian Walls -
Jared Camins-Esakov -
Marcel de Rooy -
Paul Poulain