Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71868
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.53 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 13:51:31 +0100
Message-ID: <CAEZPtU4FQX51VN=g4po6tPG3TjS6UDuEK8iRORZSyAJc=WMS+A@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: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length
 and integer
From: pierre.php@gmail.com (Pierre Joye)

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.

No, it is open to common sense and give us the opportunity to break
ABI if we like to in x.y+1. We did that in 5.4 and 5.5.

>  In my interpretation this rule is meant to allow
> small changes, affecting only few extensions and where it would be
> stupid to defer the.

To defer the ...?

And that's your interpretation, which is your good right. However the
release RFC allows us to introduce ABI breakages if desired and
accepted.

>
> 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.


At least you did not loose your sense of humor.


Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org