Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50503
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type
         :content-transfer-encoding;
        b=j/dnh19RAHQMLGmf3TWa+o+rpPa5+EeJHG6WYlnWQrctRiy1QFKZvw1uDrkZ0EJRPs
         RqiJzOCWTyMRBfpE+Z0WLgKK/osXHcjGhwYnxGOFMB4IE8Mw6Dly9VUfxiTtY2qPWT/U
         Fg6RwITbSdiT3XrKGuuPLS120uu4UDBUZjFgc=
MIME-Version: 1.0
Sender: patrick.allaert@gmail.com
In-Reply-To: <EBD83EAA-18C4-4F0D-ABE3-C2F8D127FBF3@php.net>
References: <AANLkTi=coWEEMNnr_SsTCo7HaXUPRwcJg7fUz=NjA8nq@mail.gmail.com>
	<73.C4.59959.876BBEC4@pb1.pair.com>
	<AANLkTikhwbTvpNeW6tufCy=cJzDN3zxaZWtyJPeFEvc=@mail.gmail.com>
	<EBD83EAA-18C4-4F0D-ABE3-C2F8D127FBF3@php.net>
Date: Thu, 25 Nov 2010 08:49:50 +0100
Message-ID: <AANLkTi=PHHywu1oN3GJux0GuW-11RLOKGBEFQsya57bK@mail.gmail.com>
To: Davey Shafik <davey@php.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: Hold off 5.4
From: patrickallaert@php.net (Patrick ALLAERT)

2010/11/25 Davey Shafik <davey@php.net>:
>
> On Nov 24, 2010, at 8:29 PM, Pierre Joye wrote:
>
>> On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner <mike@php.net> wrote:
>>> On 11/23/2010 02:30 AM, Felipe Pena wrote:
>>
>>>> 5.4 should be hold off until we solved the listed issues and the
>>>> release management RFC gets discussed and hopefully approved.
>
> The reality is that trunk is not going to be 5.4; it cannot be in its cur=
rent state.
>
> The reason behind ditching the unicode php6 was to enable innovation in t=
runk. This meant
> we could have traits, type hinting, apc in core etc, as well as internal =
enhancements, the new lemon
> parser etc. Regardless of the arguments and unresolved issues, this IS ha=
ppening, and IS a good thing.
>
> The goal then was to essentially take the 5.3 branch, create a 5.4 branch=
, cherry pick commits to trunk
> and apply them to the 5.4 branch and end up with a stable build. Unfortun=
ately, subversion merging sucks.
>
> This is an unreliable, laborious, crappy method for creating stable branc=
hes, and managing the
> repo. Worse yet, SVN's merge-tracking/branch reintegration also sucks, so=
 creating feature branches and
> re-integrating is also a pretty crappy solution.
>
> So, with the BC breaks committed to trunk (register globals) or that we w=
ant to commit to trunk (magic quotes), as
> well as the code without consensus, creating a stable 5.4 branch is going=
 to be a lot of work.
>
> Now, I'm no advocate of git (I've yet to jump on the bandwagon for my mai=
n repo, but have several small projects on
> github), but it seems that it's capabilities would make these things much=
 more trivial. Obviously: not a solution for now.
>
> We need to get our repo in order first, then we can start talking about 5=
.4. The RMs need to make a definitive
> stand about how the repo will be managed, and explain to us how that's go=
ing to trickle down to our personal habits.
>
> This doesn't seem the ideal time to introduce a new toolchain, so stickin=
g with SVN, we should =C2=A0maintain 4 branches, 5.2 (security only), 5.3 (=
bug fixes + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (B=
C breaks).
>
> Non-agreed upon enhancements, potential BC breaks, all should be done in =
feature branches. This gives people buildable
> (hopefully) branches to use for testing, revision control for those devel=
oping the features, and unmuddied commit histories
> to more easily pull those changes into the appropriate branches.
>
> - Davey
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

I think Davey has a clear view and a good explanation about the
current situation.
Trunk has been used for both short and long term development hence the
difficulties to agree that trunk is about 5.4 or +.

In a first place, we should decide on what to have for 5.4 and what to
leave for the future.

A technical way to do it would be to use git-svn locally, starting
from the PHP_5_3 branch and merging it with trunk. git rebase -i can
then be used easily to remove all the commits we don't want to appear
in 5.4.

--=20
Patrick