Rene, The issue is certainly not due the git workflow but to upgrade schemes we have.
The result of this workflow for us is that it is easier to find to which branches a particular commit is added as by merging forward the commit id of the actual fix doesn't change. so instead of looking in each branch for a bit of code you can look for a commit id on a branches log. On Wed, Feb 14, 2018 at 4:54 PM, Rene Moser <m...@renemoser.net> wrote: > Hi all > > Thanks for taking care of this issue. > > However, I wonder how we can prevent such issues in the future and > wondering if this "incident" has its orginos by our current git workflow. > > I find the workflow "commit to stable branch --> merge back to master" > is inconvenient. Because at one point, the branches divert too much > (think of refactorings on master branch) and a merge back to the master > would not work or would break. > > In most of the project I work with, there are stable-branches as well > but any fix (and feature of course) has to be on master first. Any > serious fix could be cherry picked to stable branches (there may be more > than one) if applicable or an alternative fix could be made. stable > branches never receives merges from or to master branch. > > To be honest, I haven't seen any project adopting this workflow, I > wondered why and how come we have this workflow. > > Thanks for clarification. > > René > > > > On 02/12/2018 02:29 PM, Rohit Yadav wrote: > > All, > > > > > > Some of us have discussed and found an upgrade path issue that only > affects the 4.10.0.0 users who may see missing columns in certain tables > post upgrading to 4.11.0.0 version. > > > > > > The issue is/was that at the time 4.10.0.0 was released, PRs were merged > to the 'then' master branch that made changes to the 4.9.3.0->4.10.0.0 > upgrade path instead of the 4.10.0.0->4.11.0.0 upgrade path. One of such > change was an ALTER statement that added a new column `service_package_id`, > and if 4.10.0.0 version is upgraded to 4.11.0.0 such environments may > report sql related errors related to this column. > > > > > > (My colleagues Bobby and Ernie may chip in their findings and test > results as well) > > > > > > Pull request: https://github.com/apache/cloudstack/pull/2452 > > > > Jira ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-10285 > > > > > > The proposed workaround is to move the changes to the expected upgrade > path of 4.10.0.0->4.11.0.0. This is *not ideal* given 4.11.0.0 is released > but at least 4.10.0.0 users who may want to upgrade to 4.11.1.0 or later > won't face the issue. > > > > > > The proposed workaround for current 4.10.0.0 users who may want to > upgrade to 4.11.0.0 is to run the following sql statements from the PR > above before upgrading to 4.11.0.0: (we may discuss and update the > release notes website as well) > > > > > > ### start sql ### > > > > > > use cloud; > > > > > > CREATE TABLE IF NOT EXISTS `cloud`.`netscaler_servicepackages` ( > > `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT 'id', > > `uuid` varchar(255) UNIQUE, > > `name` varchar(255) UNIQUE COMMENT 'name of the service package', > > `description` varchar(255) COMMENT 'description of the service > package', > > PRIMARY KEY (`id`) > > ) ENGINE=InnoDB DEFAULT CHARSET=utf8; > > > > CREATE TABLE IF NOT EXISTS `cloud`.`external_netscaler_controlcenter` ( > > `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT 'id', > > `uuid` varchar(255) UNIQUE, > > `username` varchar(255) COMMENT 'username of the NCC', > > `password` varchar(255) COMMENT 'password of NCC', > > `ncc_ip` varchar(255) COMMENT 'IP of NCC Manager', > > `num_retries` bigint unsigned NOT NULL default 2 COMMENT 'Number of > retries in ncc for command failure', > > PRIMARY KEY (`id`) > > ) ENGINE=InnoDB DEFAULT CHARSET=utf8; > > > > ALTER TABLE `cloud`.`sslcerts` ADD COLUMN `name` varchar(255) NULL > default NULL COMMENT 'Name of the Certificate'; > > ALTER TABLE `cloud`.`network_offerings` ADD COLUMN `service_package_id` > varchar(255) NULL default NULL COMMENT 'Netscaler ControlCenter Service > Package'; > > > > > > DROP VIEW IF EXISTS `cloud`.`user_view`; > > CREATE VIEW `cloud`.`user_view` AS > > select > > user.id, > > user.uuid, > > user.username, > > user.password, > > user.firstname, > > user.lastname, > > user.email, > > user.state, > > user.api_key, > > user.secret_key, > > user.created, > > user.removed, > > user.timezone, > > user.registration_token, > > user.is_registered, > > user.incorrect_login_attempts, > > user.source, > > user.default, > > account.id account_id, > > account.uuid account_uuid, > > account.account_name account_name, > > account.type account_type, > > account.role_id account_role_id, > > domain.id domain_id, > > domain.uuid domain_uuid, > > domain.name domain_name, > > domain.path domain_path, > > async_job.id job_id, > > async_job.uuid job_uuid, > > async_job.job_status job_status, > > async_job.account_id job_account_id > > from > > `cloud`.`user` > > inner join > > `cloud`.`account` ON user.account_id = account.id > > inner join > > `cloud`.`domain` ON account.domain_id = domain.id > > left join > > `cloud`.`async_job` ON async_job.instance_id = user.id > > and async_job.instance_type = 'User' > > and async_job.job_status = 0; > > > > > > ### end sql ### > > > > > > Thoughts, perhaps other ways to tackle this? > > > > > > - Rohit > > > > <https://cloudstack.apache.org> > > > > > > > > rohit.ya...@shapeblue.com > > www.shapeblue.com > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > > @shapeblue > > > > > > > > > -- Daan
