Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71875
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
To: Pierre Joye <pierre.php@gmail.com>
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>
In-Reply-To: <CAEZPtU4FQX51VN=g4po6tPG3TjS6UDuEK8iRORZSyAJc=WMS+A@mail.gmail.com>
References: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com>
	 <1391171792.2941.130.camel@guybrush>
	 <CAEZPtU4FQX51VN=g4po6tPG3TjS6UDuEK8iRORZSyAJc=WMS+A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 31 Jan 2014 14:27:54 +0100
Message-ID: <1391174874.2941.160.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string
 length and integer
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Fri, 2014-01-31 at 13:51 +0100, Pierre Joye wrote:
> On Fri, Jan 31, 2014 at 1:36 PM, Johannes Schlüter
> <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.

So what is the purpose of the rule? If a "normal" RFC vote can do
whatever it likes why have that rule? As you are the author I'm happy to
learn your interpretation.

> >  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 ...?

... the change.

> At least you did not loose your sense of humor.

Yes, humor indeed helps if the one who creates the rules is also the one
who tries to bend it the most.

johannes