Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73563
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAMUwpuQZrHBVkipgfbtaPxwUqGBGoX=AgAJrzXWCS5GATQcsbA@mail.gmail.com>
References: <CAMUwpuQZrHBVkipgfbtaPxwUqGBGoX=AgAJrzXWCS5GATQcsbA@mail.gmail.com>
Date: Thu, 3 Apr 2014 04:06:58 -0700
Message-ID: <CAKOpQSwZ9-NNwHMSt2rrMw7s63bxf7+NYtAeDC-F=BDy+YVXTg@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b47286e5d879504f6216623
Subject: Re: [PHP-DEV] Branching PHP6
From: kris.craig@gmail.com (Kris Craig)

--047d7b47286e5d879504f6216623
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 2, 2014 at 4:33 AM, Julien Pauli <jpauli@php.net> wrote:

> Hey ,
>
> We've been talking about PHP6 for several weeks now.
>
> From what I understand, we agreed on :
>
> - We must release a new major version, ASAP I'd say
> - It should be named "PHP6"
> - It should break BC where needed, and introduce new concepts
> - The main concept to concentrate on is Unicode implementation
> - All ideas have been grouped at https://wiki.php.net/ideas/php6
> - We go for a 2 year developpment iteration
>
>
> All in one, 5.6 is going to be released in few months, and we now must
> concentrate on PHP6.
>
> For this, there are two needs :
> - Start writing RFCs, PHP6 specific, and start debating ideas on an
> "official" basis (RFCs + mail discussions)
> - Branch PHP6 , so that we can start hacking and get more motivations.
>
> Thoughts about how/when to branch PHP6 ?
>
>
> Julien Pauli
>

I think we should use this opportunity to start following a more Git-style
branching model.  Currently, every maintenance release increment exists as
its own separate branch; i.e. "PHP-5.5.10" is a branch and "PHP-5.5.11" is
a branch, and so on.  This is redundant because we already have a tag for
each release.  Additionally, it also forces us to target features for one
or more specific maintenance version increments.  A more flexible approach
would be to have each increment reflect the totality of what's been merged
in as stable as of whenever the increment went to release.

This can get complicated and confusing so I'll do my best to articulate
exactly what it is I'm proposing and why.  It's very similar in principle
to how the Gitflow model works..

Under the current model (as best as I can decipher from gitk, at least),
the PHP-5.4 branch merges into master and PHP-5.5.  PHP-5.5 then merges
into PHP-5.6.  PHP-5.6 (the most recent increment) then merges into master.
 Each of these minor versions are then branched off into a maintenance
version branch every time a maintenance release occurs.  These branches
eventually just remain dead, at least some without being merged back into
anything.  It's already a confusing mess and it's only going to get worse
at this rate.  Just type "gitk --all" sometime and see how much of it you
can make sense of without getting a migraine.

What I'm suggesting is a cleaner, more logical approach that doesn't force
us to keep a dead branch for every maintenance release.  Let's start with
creating the PHP-6 branch....


   1. Create branch PHP-6 based off of master (master->PHP-6).
   2. Commits related to work on PHP 6.  See explanation about feature
   branching below.
   3. When we decide we have enough for a minor release, create a new
   branch based off of PHP-6 (PHP-6->Release-PHP-6.0).
      - This is the cuf-off point for noteworthy new features and whatnot.
      - Commits on this branch will pertain mostly to bug fixes and maybe
      trivial feature changes/etc.
      - Work on everything else will continue in parallel on PHP-6.
      - Release-PHP-6.0 will occasionally be merged into PHP-6
      (PHP-6<-Release-PHP-6.0).  However, commits to PHP-6 will NOT be merged
      into the minor release branch.
      - If we have a bug fix that we want to incorporate into an
      older-yet-supported version, make the change on one of the
Release branches
      then merge it into the other-- if that can be done without
creating a merge
      conflict.  Otherwise, we'd want to manually commit it to the
others.  Just
      depends on how different the surrounding code is between the minor
      increments.
   4. When the Release-PHP-6.0 branch is deemed ready for a release
   (commits to that point could be treated as release candidates):
      - Tag the commit with the maintenance release version.  The first one
      would be "PHP-6.0.0".
      - This would be a good time to merge it into PHP-6, as well.
   5. Repeat Step 4 for the duration of the 6.0 lifecycle.  Each subsequent
   commit tag will increment "PHP-6.0.1", "PHP-6.0.2", and so on.  Again:
    Commits to PHP-6 will NOT be merged here; however, commits here will be
   merged back into PHP-6.
   6. When the PHP-6 branch is ready for a new minor version increment,
   repeat Steps 3 - 5, except increment it to "Release-PHP-6.1" and so-on.
   7. When a minor release's lifecycle is over and we're no longer
   supporting it (i.e. there will be no more maintenance releases), merge the
   release branch into PHP-6 (i.e. PHP-6<-Release-PHP-6.0) and delete the
   release branch.  So long as you use the "--no-ff" switch when merging, the
   complete history for that former branch will be preserved and the chart
   will look MUCH nicer!

This model would allow us to have a much more organized and easy to follow
commit history.  Every single version increment will still be accessible
via tags just as they are now and the temporary Release branches will
appear in the history even after they're gone.

One of the advantages to this approach is that people will no longer have
to decide which minor increment(s) to target something for, nor will they
have to worry about having to merge it into a ton of different places.  It
will also make it a LOT easier to enforce a cut-off for new features/etc
into a minor release.  It'll force us to limit maintenance releases to,
well, maintenance.  Meanwhile, if something isn't there in time for 6.2,
it'll just go into 6.3 instead if it's ready by then.  A developer would
then simply have to decide whether something should be targetted for the
next minor release (i.e. commit to PHP-6) or whether it's within the scope
of a maintenance release (i.e. commit to one or more of Release-PHP-6.x
then merge back into PHP-6).

On a separate note, as alluded to in Step 2, I'd also recommend using
feature branches instead of committing directly into the "trunk" for a
given version.  For example, I create a LOCAL branch called "Bug_53333" off
of "Release-PHP-6.0".  I make several commits while working on fixing this
bug over the course of several days.  When it's done, just like with the
Release branches, I merge the feature branch back into Release-PHP-6.0
(using "--no-ff" to preserve the commit history and feature branch name at
the merge point) and delete the feature branch.  Note that the feature
branch is never pushed to the host repo; it exists solely on the dev's
local machine.  However, when the dev pushes Release-PHP-6.0, the commits
and the branch name will appear in the history, which will make it a lot
easier to read.  Furthermore, this has the advantage of making sure all the
commits related to the fix are pushed at once so the release manager
doesn't have to worry about a partial bug fix sitting there potentially
breaking the release, forcing them to either rewind or wait for the other
commits to arrive.

I didn't include the feature branch part in the numbered list because I
wanted to communicate the basic structure as clearly as possible.
 Furthermore, it'll still work without using local feature branches, though
using them solves a lot of problems and makes the history more
human-friendly.


I realize this may look complicated-- particularly to people more
accustomed to Subversion-style branching-- but the benefits far exceed any
learning curve involved.  Furthermore, we could start doing this with PHP
6; it wouldn't have any effect on how we're doing the branching for PHP 5.

If we go with that model, we could get started on the new PHP-6 branch
right away or whenever we all decide it's time to get it underway.


Thoughts?  If it'll help, I can create a mock repo to demonstrate this
approach and how much easier it is to review and work with.

--Kris

--047d7b47286e5d879504f6216623--