On Mon, Apr 9, 2012 at 2:57 PM, Stas Malyshev <smalys...@sugarcrm.com>wrote:
> Hi! > > > release candidates. I mean, we're still planning on having multiple > > release candidates before an actual release, right? If so, then > > Not if we can avoid it. If we don't have critical bugs in RC1, we > release it. > > > obviously we'll need a way to commit those changes. If they're not made > > on the RC branch, then where were you thinking they should go, and how > > would we then apply those bugfixes to the 5.4 trunk if not through a > merge? > > If you have bugfix for 5.4, commit it into 5.4. If it's critical for > current release, it will be pulled by RM into the release, otherwise he > automatically becomes part of the next release. > 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 Git IMHO. The appropriate way to do this would be to have these bugfixes pushed as separate branches based off of the release branch, then the RM chooses whether or not to merge each one back into the release branch. This takes advantage of Git's built-in branching/merging functionality without the need for manual 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. --Kris > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 >
