Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71885
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH-PCH5TO486f2E589qj=MTbV9sBe68zcdn3B3vhgov-jLiFHg@mail.gmail.com>
References: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com>
	<1391171792.2941.130.camel@guybrush>
	<CAH-PCH5TO486f2E589qj=MTbV9sBe68zcdn3B3vhgov-jLiFHg@mail.gmail.com>
Date: Fri, 31 Jan 2014 18:42:26 +0100
Message-ID: <CAH-PCH7Dzm5DPNT0rcdXyrEELLHfjmZXdaz+2Ow759EQ3KWfkA@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=001a11c1db6c8455ae04f147b2e7
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length
 and integer
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a11c1db6c8455ae04f147b2e7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 31, 2014 at 5:19 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:

>
>
>
> On Fri, Jan 31, 2014 at 1:36 PM, Johannes Schl=C3=BCter <johannes@schluet=
ers.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 th=
e
> 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 mor=
e
> 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 wil=
l
> 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, whi=
ch
> 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 th=
e
> roadmap, so we can have these changes merged into an official branch wher=
e
> there are more people watching and helping it stabilize.
>
> --
> Ferenc Kov=C3=A1cs
> @Tyr43l - http://tyrael.hu
>

to clarify by BC break I meant internal API compatibility break of course,
so it would only affect the extension developers directly (and affecting
the users indirectly through the lack of extension support for the new
version).

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a11c1db6c8455ae04f147b2e7--