Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50500
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 206.46.173.9 as permitted sender)
MIME-version: 1.0 (Apple Message framework v1081)
Content-type: text/plain; charset=us-ascii
In-reply-to: <AANLkTikhwbTvpNeW6tufCy=cJzDN3zxaZWtyJPeFEvc=@mail.gmail.com>
Date: Thu, 25 Nov 2010 02:16:42 -0500
Content-transfer-encoding: quoted-printable
Message-ID: <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>
To: PHP Internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] Re: Hold off 5.4
From: davey@php.net (Davey Shafik)


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:
>=20
>>> 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 =
current state.

The reason behind ditching the unicode php6 was to enable innovation in =
trunk. 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 =
happening, 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. =
Unfortunately, subversion merging sucks.

This is an unreliable, laborious, crappy method for creating stable =
branches, and managing the
repo. Worse yet, SVN's merge-tracking/branch reintegration also sucks, =
so creating feature branches and=20
re-integrating is also a pretty crappy solution.

So, with the BC breaks committed to trunk (register globals) or that we =
want 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 =
main 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=20
stand about how the repo will be managed, and explain to us how that's =
going to trickle down to our personal habits.=20

This doesn't seem the ideal time to introduce a new toolchain, so =
sticking with SVN, we should  maintain 4 branches, 5.2 (security only), =
5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC =
breaks), 6.0 (BC 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 =
developing the features, and unmuddied commit histories
to more easily pull those changes into the appropriate branches.

- Davey=