Stas, On Mon, Apr 9, 2012 at 2:07 PM, Stas Malyshev <smalys...@sugarcrm.com>wrote:
> Hi! > > > version of a "Release-x.xx" branch. I would suggest allowing commits on > > that branch, but *only* if they're bugfixes or minor housekeeping. Each > > I don't want to do this, because this would very quickly lead us back to > old chaotic situation where people commit stuff at the last moment and > it's not properly tested. I prefer to have defined merge points. > > > commit would basically be the equivalent of a release candidate (i.e. > > initial branch commit would be RC1, next commit RC2, etc). > > > > Then when it's time to pull the trigger, the final commit on that branch > > will be the actual release. Then merge that branch back into PHP-5.4. > > That's what I don't want to do. I don't want people to be > live-committing into release branch and then merge it back to dev > branch. I want release branch be clean and frozen as much as possible, > and people committing to dev branch as needed. No last-minute bugfixes > either unless it's a bug that absolutely breaks the release - otherwise > it'll be released in a month, most bugs can wait for a month without any > problem, given that they waited till now. > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > What I'm referring to is the same kind of bugfixes/etc that go into new release candidates. I mean, we're still planning on having multiple release candidates before an actual release, right? If so, then 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? --Kris
