Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50544
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.11 as permitted sender)
MIME-version: 1.0 (Apple Message framework v1081)
Content-type: text/plain; charset=us-ascii
In-reply-to: <alpine.DEB.2.00.1011251358400.4718@kossu.derickrethans.nl>
Date: Thu, 25 Nov 2010 12:08:51 -0500
Cc: PHP Internals <internals@lists.php.net>
Content-transfer-encoding: quoted-printable
Message-ID: <E99A96D6-97A0-4691-B40C-0AB8629C2BA4@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>
 <alpine.DEB.2.00.1011251358400.4718@kossu.derickrethans.nl>
To: Derick Rethans <derick@php.net>
Subject: Re: [PHP-DEV] Re: Hold off 5.4
From: davey@php.net (Davey Shafik)


On Nov 25, 2010, at 9:05 AM, Derick Rethans wrote:

> On Thu, 25 Nov 2010, Davey Shafik wrote:
>=20
>> The goal then was to essentially take the 5.3 branch, create a 5.4=20
>> branch, cherry pick commits to trunk and apply them to the 5.4 branch=20=

>> and end up with a stable build. Unfortunately, subversion merging=20
>> sucks.
>=20
> This has nothing to do with any sort of version control sucking. =
Cherry=20
> picking is hard! It only works if you get one feature in one commit,=20=

> instead of many several, with other changes in between, without many=20=

> dependices between patches. PHP isn't like that, especially with=20
> Dmitry's engine changing patches.

While it's true the tools are not to blame, they're not HELPING the =
situation
as much as some people seemed to think when the plan was thought out.
Everything you say simply backs up my point that SVN is not the right =
tool
for the model that seemed to be the goal.

>=20
>> This doesn't seem the ideal time to introduce a new toolchain, so=20
>> sticking with SVN, we should maintain 4 branches, 5.2 (security =
only),=20
>> 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC=20
>> breaks), 6.0 (BC breaks).
>=20
> Four branches? Are you going to help?

I'm not sure why you seem to think this is so difficult. 5.2 would =
(ideally) have very
little work going on. 5.3 would have somewhat more work, but is also =
closed to 5.4
so committing to two branches would be somewhat easier. 5.4 wouldn't be =
released
till all features are complete, then it too moves to a bug =
fixes+security release and 5.2
gets sunsetted (this is why we need more reliable schedules). If we have =
releases every
6 months, or every 12 months (for example), it would mean each X.Y would =
last=20
12 or 24 months respectively.

>=20
>> Non-agreed upon enhancements, potential BC breaks, all should be done=20=

>> in feature branches.
>=20
> That's a good theoretical point of view. And I maintain it doesn't =
work.=20
> It makes it for example very difficult to try out multiple new =
features=20
> at the same time; to say, to try to figure our whethr your app will=20
> still works. It's also a lot more egocentric thing, instead of=20
> collaboration. You want your stuff exposed to as many developers as=20
> possible (that's also why I am not a fan of DVCS, because it reduces=20=

> that exposure drastically).

Actually, it makes things easier, now you can simply do:

svn co http://svn.php.net/r/php/php-src/branches/PHP_5_3 php-5.3
svn diff http://svn.php.net/r/php/php-src/branches/traits =
http://svn.php.net/r/php/php-src/branches/PHP_5_3 | patch ./php-5.3
svn diff http://svn.php.net/r/php/php-src/branches/derick-typehints =
http://svn.php.net/r/php/php-src/branches/PHP_5_3 | patch ./php-5.3

It means you get easy contiguous patches from any branch, over any =
number of commits (solving your issue above)

And, as already pointed out, the collaboration possible through github =
is far more than we currently enjoy via SVN and ML/IRC today - but =
again, I don't want to propose git as a solution.

As for talk of 6.0 as opposed to 5.4, nobody is going to risk putting =
their BC compatible features in a 6.0 release and then take 2 years to =
be adopted unless we force it (the committing to 6.0, not the adoption), =
when they can just create 5.5, 5.6, 5.14 and get it out before the =
stigma of the jump to 6.0 adoption. I don't have a solution for this =
that doesn't suck (forcing 6.0, or managing two branches, with all the =
same features, 5.x without the BC breaks, 6.0 with)

- Davey=