Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50504
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain iki.fi designates 213.243.153.189 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <EBD83EAA-18C4-4F0D-ABE3-C2F8D127FBF3@php.net>
Date: Thu, 25 Nov 2010 10:24:30 +0200
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <3EA67EA2-A9B1-4DFB-8A30-05B37BCA313B@iki.fi>
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>
To: Davey Shafik <davey@php.net>
Subject: Re: [PHP-DEV] Re: Hold off 5.4
From: jani.taskinen@iki.fi (Jani Taskinen)

Who says it has to be 5.4? People seem to be a bit fixated on the =
version there.=20
Major BC breaks just means the version released from trunk is 6.0. And =
it's just a number. Big number, but still just a number.

Merging (by and or by magic :) features into branch created from 5.3 =
just sounds like plane crash waiting to happen..

---Jani



On Nov 25, 2010, at 9:16 AM, Davey Shafik wrote:

>=20
> On Nov 24, 2010, at 8:29 PM, Pierre Joye wrote:
>=20
>> 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.
>=20
> The reality is that trunk is not going to be 5.4; it cannot be in its =
current state.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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
>=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).
>=20
> 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.
>=20
> - Davey
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20