rafaelweingartner commented on issue #2584: Enhance and cleanup DatabaseUpgradeChecker URL: https://github.com/apache/cloudstack/pull/2584#issuecomment-382832933 Thanks @khos2ow. This is a great proposal to simplify the upgrade path code. You already have another PR for master, that is what I call being proactive! I see no problem in opening this PR to 4.11. I asked because it could cause more trouble for you during the merge forward. I mean, it could cause trouble for the committer, which would, in turn, ask for your help. I got your solution idea. However, I still have one doubt. Sorry, if this is clear in the code, but I normally prefer to understand what I am dealing with before coding/reviewing. There is one thing you mention that called my attention: > it means that we can inject a version in the middle of the hierarchy as well (e.g. between existing 4.9.3.0 AND 4.10.0.0 Using this PR, what scripts would be executed in the following scenario? * ACS most recent version is 4.11.0.0 * There are old, but still maintained version 4.10 and 4.9 * A user is in version 4.9.3.0 * Let’s say that we create a version 4.9.4.0 that executes some script in the database. This change is also pushed forward and is then released in version 4.11.1.0. * If the user upgrades to 4.9.4.0, he/she will get the change, and then it is clear the path to 4.11.1.0 * If the user upgrades directly to 4.11.1.0, it is also clear the upgrade path * What happens if the user goes to 4.10.0.0 (from 4.9.3.0)? Assuming that 4.10 was released before 4.9.4.0 (then, it does not have the new scripts). When the user goes from 4.10 to 4.11.1. Will the scripts from 4.9.4.0 be executed?
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
