Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71882
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1391171792.2941.130.camel@guybrush>
References: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com>
	<1391171792.2941.130.camel@guybrush>
Date: Fri, 31 Jan 2014 17:19:36 +0100
Message-ID: <CAH-PCH5TO486f2E589qj=MTbV9sBe68zcdn3B3vhgov-jLiFHg@mail.gmail.com>
To: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>
Cc: Anatol Belski <ab@php.net>, PHP Developers Mailing List <internals@lists.php.net>, 
	Matt Ficken <mattficken@php.net>, "Stephen A. Zarkos" <szarkos@php.net>
Content-Type: multipart/alternative; boundary=001a1133c1864456cf04f1468a98
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length
 and integer
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a1133c1864456cf04f1468a98
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 31, 2014 at 1:36 PM, Johannes Schl=C3=BCter
<johannes@schlueters.de>wrote:

> On Mon, 2014-01-27 at 21:15 +0100, Anatol Belski wrote:
> > https://wiki.php.net/rfc/size_t_and_int64
>
> It is my understanding that part of the reason for the release workflow
> RFC was that if patches miss the mark they don't have to wait for long
> till the next release comes.
>
> In this case here we have 5.6.0alpaha1 out. Adding a major API change
> touching each and every file can't be added to 5.6 anymore.
>
>
> Also the release process RFC says
>
>          x.y.z to x.y+1.z
>             [...]
>             ABI and API can be broken (internals), src compatibility
>         should
>             be kept if possible, while breakages are allowed
>
> This rule contains many things that "can" and "should" and thus is open
> to interprettation. In my interpretation this rule is meant to allow
> small changes, affecting only few extensions and where it would be
> stupid to defer the.
>
> I think adding this patch to 5.x therefore would be quite some bending
> of that rule and that combined with the fact that it is late makes me
> believe that proposing this for 5.6 is illegal.
>
> johannes
>
>
I think that calling it "illegal" is a bit streching it (because of the
lack of definitive wording of the releaseprocess RFC).
Personally I agree that this would be a pretty big BC break, and given the
fact that one of the goals of the new release process was to improve the
adoption rates of the new versions, plus the fact that it is more and more
likely that PHP-next(after 5.6) will be a major version where such change
has a better place, I've decided to vote no.
Based on the past experiences, I think if we accept the RFC, maybe we will
have enough time to stabilize the code to not miss the final release of
5.6.0, but there will be a bunch of widely used extensions out there, which
won't be supporting these changes for a while.

I would be happy if we could keep the discussion civil, even though that I
can understand the frustration of those who are really want this feature
ASAP or even contributed their time to make it happen.
For me, the most important thing is to not let this effort to be wasted,
even if it doesn't make it into 5.6, so as I mentioned in my previous
mails, I think it would be really important to have a major version on the
roadmap, so we can have these changes merged into an official branch where
there are more people watching and helping it stabilize.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a1133c1864456cf04f1468a98--