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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
