Re: release process with git
Hi!
> My concern is that merge conflicts can occur when cherry-picking in this
> manner. It's just generally not a "best practices" approach when using
Which merge conflicts? Diff between 5.4 and 5.4.X will never be big
enough to have any conflicts. It's just 2 weeks of stable version code.
> cherry-picking. These fixes can then be merged back into trunk, so the
> end result is the same but with far less manual work and less potential
> for human error.
I'm OK with some manual work, we won't have that much (only for critical
bugs). I don't want to merge release branch into dev branch since it
contains release-only stuff that doesn't have to be in dev branch, and I
want merges to be one direction only - from dev to release, I don't want
people putting code into release branch after RC1 unless it is an
emergency. Otherwise we get much slower release cycles since each change
basically sets us back 2 weeks.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Thread (30 messages)