Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73602
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <688A2215-A79A-417B-8E7A-76CF03DF9F35@gmail.com>
References: <CAMUwpuQZrHBVkipgfbtaPxwUqGBGoX=AgAJrzXWCS5GATQcsbA@mail.gmail.com>
	<CAKOpQSwZ9-NNwHMSt2rrMw7s63bxf7+NYtAeDC-F=BDy+YVXTg@mail.gmail.com>
	<1396523991.2982.340.camel@guybrush>
	<CAKOpQSw4CpaZLdB0tkeorwnO+Ax9aYqFmMYasxwRwDLok8BZZw@mail.gmail.com>
	<1396527638.2982.350.camel@guybrush>
	<CAKOpQSw9=CgNcfS16=HccKDwKRo_oee_dv9LsDt_JoLyq3i2+Q@mail.gmail.com>
	<533F9C11.9000303@sugarcrm.com>
	<688A2215-A79A-417B-8E7A-76CF03DF9F35@gmail.com>
Date: Sat, 5 Apr 2014 00:30:08 -0700
Message-ID: <CAKOpQSyCKtpnTBWuxx7Geae0+Q8oPB3BjBFUJVDUqYDZv-+iEg@mail.gmail.com>
To: Alexey Zakhlestin <indeyets@gmail.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>, 
	Julien Pauli <jpauli@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c303a292805904f6469ab0
Subject: Re: [PHP-DEV] Branching PHP6
From: kris.craig@gmail.com (Kris Craig)

--001a11c303a292805904f6469ab0
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Apr 5, 2014 at 12:19 AM, Alexey Zakhlestin <indeyets@gmail.com>wrote:

>
> On 05 Apr 2014, at 10:00, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
>
> > makes it a nightmare to read.  Furthermore, there's simply no need to
> have
> >> an ever-increasing number of dead branches that lead nowhere and never
> >> merge back.  If somebody wants to find a specific version, that's what
> tags
> >
> > Branches are dirt-cheap in git, so dead branches is not a problem.
>

I disagree.  When you have far more dead branches than active ones, with
the gap only widening as time goes forward, it becomes increasingly
difficult to quickly locate active branches of development.  There's simply
no reason to leave dead branches out there when quick access to past
versions can be achieved through tags, which we're already doing anyway.


> Also,
> > the only dead branches are supposed to be release branches and very
> > rarely feature branches, all the rest should be done in private branches
> > and submitted as pull request.
>

In ideal Git workflow, release branches should never lie dead like this.
 Instead, they are merged back into the trunk branches-- no fast forward to
preserve history-- and deleted.  Tags are used to enable users to quickly
go back to key points in history; i.e. version releases.

Regarding RM control, the workflow I've suggested would not disrupt that at
all.  The RM would still have full control over what goes onto the release
branch and when, as well as where and when tags are applied.  But in this
scenario, once the lifecycle of that release is over, the release branch is
merged back in one last time and deleted.  The history is preserved but it
doesn't leave a dead branch.

If we had been using this approach to-date, we'd have just a few branches
instead of, well, dozens, most of which are defunct and no longer serve any
purpose except to clutter.


> The usual git workflow which I've seen in the wild is:
>
> 1. release branch is created
> 2. release-specific commits are added
> 3. tag (optionally signed) is created
> 4. branch is removed
>
> In case development has to be restarted (for hotfix-patch), new branch is
> created from the tag-point.
>
> The advantage is, that "branches" represent points of active development
> and tags represent history.


That's essentially correct.  What we're doing right now is having more and
more branches created to represent points of development that are no longer
active.  That is, in fact, exactly what tags are for in Git.

--Kris

--001a11c303a292805904f6469ab0--