Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76928
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.171 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <CAMUwpuQ6xm=tyP-QNfDd0dswLqvPoCOV+x94ZPD7z=O-1B3ObQ@mail.gmail.com>
References: <CAMUwpuQ6xm=tyP-QNfDd0dswLqvPoCOV+x94ZPD7z=O-1B3ObQ@mail.gmail.com>
Date: Thu, 28 Aug 2014 21:07:10 +0100
Message-ID: <CAGAGxbZLr9Wq0EBGRmV4624_vv=qREe1YE7PCnt3VSCSirac2Q@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Cleaning 5.3 git branches ?
From: daverandom@php.net (Chris Wright)

On 28 August 2014 19:55, Julien Pauli <jpauli@php.net> wrote:
> Hello,
>
> We all know 5.3 is now EOL.
>
> Looking at git branches, 5.0, 5.1 and 5.2 still have their respective
> main branches (which is all right and good).
>
> However, they dont have their release branch references (5.1.1 , 5.1.2
> etc...) , however they still show their own release tags, which is
> also all right.
>
> As a reminder, release *branches* (not the tags) are used by the RMs
> to actually release the version.
> RMs branch from the main repo into a release branch, and apply their
> RM-managing-stuff commits as well as backport eventual commits from
> the main branch, for CVEs, for example.
>
> Those release branches are here just for the release, and are no
> longer needed at all after the release has been released, because
> every release owns its own final git tag.

Based on this, it doesn't seem like there's any point in keeping the
branches at all after the tag is created.

I would take this proposal a step further and suggest a policy of
deleting the previous release branch when a new release is made (i.e.
when 5.6.1 is tagged, the 5.6.0 branch would be deleted).

The workflow described dictates that no changes should be made to a
branch after its corresponding tag is created, and github provides a
decent, universally accessible and familiar UI for browsing the code
of a particular tag. I would be in favour of keeping hold of a branch
until the following release is created (rather than deleting it when
that release is made) as "emergency" releases - for example when a
major security flaw is discovered after a release - could be
facilitated by keeping hold of the old branch, although even this
reasoning is highly questionable.

I really don't see the need to keep any release branches hanging
around cluttering up the place.

Thanks, Chris