Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73514
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
To: Julien Pauli <jpauli@php.net>, Ferenc Kovacs <tyrael@php.net>, David
 Soria Parra <dsp@php.net>, Stanislav Malyshev <stas@php.net>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 02 Apr 2014 14:23:59 +0200
Message-ID: <1396441439.2982.284.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Merging release branches back to parent
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

Hi RMs,

we currently use release branches which we don't merge back into the
original branch.I would like to propose to change this and merge the
release branch back into it's parent branch. To the est of my
remembrance not doing this is a reminder of SVN merge tracking annoyance
which is not relevant anymore.

The reason for this change is that it makes it hard to find out whether
a patch was part of a release or not and which release it appeared in
first.

The suggested work flow (pushes ignored) is like this:

     1. git checkout PHP-X.Y
     2. git branch PHP-X.Y.Z
     3. vim NEWS configure.in main/php_version.h && git commit (set to
        next version X.Y.Z+1)
     4. git checkout PHP-X.Y.Z
     5. test, cherry pick and release RCs as needed
     6. vim NEWS configure.in main/php_version.h && git commit (for
        release)
     7. git tag -s php-X.Y.Z
     8. git checkout PHP X.Y
     9. git merge PHP-X.Y.Z
    10. resolve merge conflict in NEWS and other files && git commit

The only change to the current procedure should be that instead of 9 and
10 one currently manually merges NEWS files.

johannes