Across versions db migration is taken care. I think this is bound to occur while working on a release, if multiple people work on the same branch with different work-in-progress features.
Could we move to flyway or liquibase which can take care of db versioning and migration? ~Rajani On 06-Mar-2014, at 2:08 am, Mike Tutkowski <mike.tutkow...@solidfire.com> wrote: > Yeah, in this case, I'm not referring to erroneous code that breaks a > person's environment (since hopefully the person wouldn't have knowingly > checked in such code), but rather, say, DB-type changes that improve the > system, but break current setups. > > Just a heads-up e-mail with some easily identifiable tag. > > Can anyone think of a good tag for this? It's not always DB related, so we > might want the tag to be more general. > > > On Wed, Mar 5, 2014 at 1:28 PM, Ian Duffy <i...@ianduffy.ie> wrote: > >> +1 to this. >> >> Having the build suddenly break due to a git pull has been very annoying! >> I usually end up searching through the commit log and doing a resets >> until I find a commit where it works. Then waiting awhile until I do a >> git pull again and hoping the code was fixed. >> >> On 5 March 2014 20:19, Mike Tutkowski <mike.tutkow...@solidfire.com> >> wrote: >>> Hi, >>> >>> I encountered a bit of a problem this morning and thought I would bring >> it >>> up for discussion. >>> >>> If we already have a policy around this, please let me know. >>> >>> So, I fetched the latest and rebased my local 4.4 development branch on >> top >>> of master. This all went just fine. >>> >>> When I rebuilt and re-started the CS Management Server, I soon realized I >>> could no longer log in from the GUI. >>> >>> As it turns out, the DB schema had been updated and so my database was >> out >>> of date. The code was querying for fields that didn't exist in my DB. >>> >>> As far as I know, the easiest way to get around this is to destroy my >>> current cloud, run the script to re-build my database, then re-create my >>> cloud, which is somewhat time consuming. >>> >>> Do we have a process in place currently in which we ask those who make >> such >>> changes to send out a notification e-mail to dev@ to give people a >> heads up >>> that updating will lead to such issues? On previous projects, we would >> send >>> out an e-mail and then people could be aware to only update if they were >>> prepared for such re-work. >>> >>> To be clear here, I'm not meaning to pick on anyone in particular...this >>> has happened several times over the course of my CloudStack development >> and >>> I expect that I, too, have checked in such code (without sending out a >>> relevant e-mail) that lead people to have to perform such a complete >>> re-build action un-expectedly. >>> >>> What do people think about this? Maybe we should just add an e-mail tag >> or >>> something and point people to the relevant commit? >>> >>> Thanks! >>> >>> -- >>> *Mike Tutkowski* >>> *Senior CloudStack Developer, SolidFire Inc.* >>> e: mike.tutkow...@solidfire.com >>> o: 303.746.7302 >>> Advancing the way the world uses the >>> cloud<http://solidfire.com/solution/overview/?video=play> >>> *(tm)* >> > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *(tm)*
