Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59568
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F835B34.5020909@sugarcrm.com>
References: <4F82878A.6030609@sugarcrm.com>
	<CAGSj+Qv+r2674T=N7zC0DhC9Xy1+6FVLw7+MYusA9pwESHBZzQ@mail.gmail.com>
	<CAKOpQSxMTUykqL1pBsfVWsYZ3rTZi7gOsrbk1yKk8ywSUbf1SA@mail.gmail.com>
	<4F834F94.1000002@sugarcrm.com>
	<CAKOpQSxvCFK+r==tgYrphepww6tnEeN=MFd_ZSTK=3=--MPAyA@mail.gmail.com>
	<4F835B34.5020909@sugarcrm.com>
Date: Mon, 9 Apr 2012 15:00:23 -0700
Message-ID: <CAKOpQSz3c6c9XBQcbAnOR7ttGxEF4hsXf2zWD=-FAZDxJJR_mw@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Kiall Mac Innes <kiall@managedit.ie>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04447f4711ef2004bd46223e
Subject: Re: [PHP-DEV] release process with git
From: kris.craig@gmail.com (Kris Craig)

--f46d04447f4711ef2004bd46223e
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 9, 2012 at 2:57 PM, Stas Malyshev <smalyshev@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
>

--f46d04447f4711ef2004bd46223e--