On Mon, Jul 7, 2014 at 3:13 PM, Zeev Suraski wrote:
>> On 7 ביול 2014, at 08:59, Andrea Faulds wrote:
>>
>>
>>> On 7 Jul 2014, at 13:57, Zeev Suraski wrote:
>>>
>>> I don't think it's a problem, because I don't think we're two years
>>> away from releasing a phpng-based version and I don't think
On Mon, Jul 7, 2014 at 2:57 PM, Zeev Suraski wrote:
>> On 7 ביול 2014, at 08:50, Andrea Faulds wrote:
>>
>>
>> The problem is that people who want to add stuff for PHP 6 feel they have to
>> add it to phpng, because if phpng is to be PHP 6, then it would need to be
>> based off that branch.
>>
On 7 Jul 2014, at 14:13, Zeev Suraski wrote:
>> On 7 ביול 2014, at 08:59, Andrea Faulds wrote:
>>
>>
>>> On 7 Jul 2014, at 13:57, Zeev Suraski wrote:
>>>
>>> I don't think it's a problem, because I don't think we're two years
>>> away from releasing a phpng-based version and I don't think i
> On 7 ביול 2014, at 08:59, Andrea Faulds wrote:
>
>
>> On 7 Jul 2014, at 13:57, Zeev Suraski wrote:
>>
>> I don't think it's a problem, because I don't think we're two years
>> away from releasing a phpng-based version and I don't think it's a
>> moving target at this point. So I agree we need
And here we go. So basically you are saying that once phpng is stabilized,
no matter the api/SRC cleanness, we are good for next. This is very bad and
I will vote -1 on anything close to this idea.
Besides that, the same kind of estimation was done for opcache, which was a
much smaller beast. They
On 7 Jul 2014, at 13:57, Zeev Suraski wrote:
> I don't think it's a problem, because I don't think we're two years
> away from releasing a phpng-based version and I don't think it's a
> moving target at this point. So I agree we need to remove these
> uncertainties.
>
> I'm going to start an R
> On 7 ביול 2014, at 08:50, Andrea Faulds wrote:
>
>
> The problem is that people who want to add stuff for PHP 6 feel they have to
> add it to phpng, because if phpng is to be PHP 6, then it would need to be
> based off that branch.
>
I don't think it's a problem, because I don't think we're t
On 7 Jul 2014, at 13:19, Pierre Joye wrote:
> I am skeptical on bigint in the engine given what is possible now in
> gmp. But yes, phpng is also a problem as it creates a total new code
> base and barely blocks any other improvements. Why? Except that bigint
> thing, I do not see many people try
On Mon, Jul 7, 2014 at 2:21 PM, Andrea Faulds wrote:
>
> On 7 Jul 2014, at 13:19, Pierre Joye wrote:
>
>> I am skeptical on bigint in the engine given what is possible now in
>> gmp. But yes, phpng is also a problem as it creates a total new code
>> base and barely blocks any other improvements.
On Mon, Jul 7, 2014 at 2:12 PM, Lester Caine wrote:
> On 07/07/14 12:31, Pierre Joye wrote:
>> I seriously hope that you take 2015 as pure example here. As I see no
>> remote chance to be ready next year. PHPNG is a huge stack of
>> undocumented perf patches far from being ready, APIs &code cleanu
On 07/07/14 12:31, Pierre Joye wrote:
> I seriously hope that you take 2015 as pure example here. As I see no
> remote chance to be ready next year. PHPNG is a huge stack of
> undocumented perf patches far from being ready, APIs &code cleanup did
> not even begin, and the existing APIs are even mor
On 7 Jul 2014, at 12:31, Pierre Joye wrote:
> I seriously hope that you take 2015 as pure example here. As I see no
> remote chance to be ready next year. PHPNG is a huge stack of
> undocumented perf patches far from being ready, APIs &code cleanup did
> not even begin, and the existing APIs are
hi,
On Sat, Jul 5, 2014 at 11:57 PM, Zeev Suraski wrote:
> While I'm not sure whether this isn't a bit premature to have this
> discussion, if we were to have this discussion, the RFC should do a much
> better job at summarizing the discussions we already had in the past.
I think it is not prem
On 6 Jul 2014, at 23:32, Kris Craig wrote:
> Andrea, I would *strongly* recommend that you accept Zeev's offer and make
> him a co-author. You did present at least a partial argument for breaking
> the convention, but I think they do have a valid grievance in that some of
> their arguments a
On 6 Jul 2014, at 23:38, Kris Craig wrote:
> Oh and a quick question: Could you clarify how many voting choices there are
> going to be? The RFC only lists "PHP 6" and "PHP 7", yet it says that a
> "plurality" will be required for a win, which means that there should be at
> least 3 or more
Oh and a quick question: Could you clarify how many voting choices there
are going to be? The RFC only lists "PHP 6" and "PHP 7", yet it says that
a "plurality" will be required for a win, which means that there should be
at least 3 or more choices. A plurality basically means that you got the
m
>
> As such I'd like to coauthor it with you and represent the case for 7.
>
Andrea, I would *strongly* recommend that you accept Zeev's offer and make
him a co-author. You did present at least a partial argument for breaking
the convention, but I think they do have a valid grievance in that some
For my $0.02, as someone who put a fair amount of effort into PHP6 (function
conversions, streams layer, etc...) I would really prefer to not call it PHP6.
Whether not not it was ever released, it was a thing, and phpng (while awesome)
is not that thing.
PHP7 seems the obvious choice, but I'm
On 6 Jul 2014, at 18:37, Zeev Suraski wrote:
> I appreciate your change!
>
> As such I'd like to coauthor it with you and represent the case for 7.
You’re welcome to edit the RFC and add a subsection with a case for 7. I’d
appreciate it if you could discuss edits to the existing Rationale wit
> On 6 ביול 2014, at 07:22, Andrea Faulds wrote:
>
>
>> On 5 Jul 2014, at 22:23, Andrea Faulds wrote:
>>
>> This RFC attempts to settle the matter once and for all with a straight
>> yes/no vote as to whether the name should be PHP 6. Should it pass, the
>> matter is settled and we actually hav
When you have infinity at your disposal, skipping 6 and taking the
next free number - 7 - makes a whole lot more sense than trying to
rewrite the archives of history (renaming 6 to Old 6).
Similarly, while there are fairly good reasons on why we shouldn't use
6, there aren't any for the next-in-l
On 6 Jul 2014, at 17:46, Lester Caine wrote:
> On 06/07/14 16:08, Andrea Faulds wrote:
>> I think it’s generally clear what’s for the new PHP 6 and what’s for the
>> old; anything from after the old PHP 6 was abandoned must be about a new PHP
>> 6, and anything from before it must be about the
On 06/07/14 16:08, Andrea Faulds wrote:
> I think it’s generally clear what’s for the new PHP 6 and what’s for the old;
> anything from after the old PHP 6 was abandoned must be about a new PHP 6,
> and anything from before it must be about the old PHP 6. If this RFC were to
> pass with people v
On 6 Jul 2014, at 16:12, Jocelyn Fournier wrote:
> It's my first post in this list, and wanted to share my external point of
> view, with a parallel with the MySQL world.
Welcome to PHP! :)
> MySQL 6 was alpha in 2007 and finally was never released.
> So far its name has never been reused (in
Hi,
Le 06/07/2014 03:13, Zeev Suraski a écrit :
I want to point out that neither options (6 nor 7) break the our
convention. PHP 6 was a live project that was worked on by many people,
and known as such by many many more; Even though it never reached GA –
there was definitely software named PH
On 6 Jul 2014, at 14:48, Lester Caine wrote:
> Andrea - Your total disregard for anything other then a a single reason
> related to books is a problem here. While printed /electronic books are
> a part of the problem with the tag PHP6, there are considerable
> additional references to that tag o
On 06/07/14 12:21, Andrea Faulds wrote:
> The RFC has been updated. I’ve backed down and made the vote be 50%+1 with
> the options PHP 6 and PHP 7. Hence only a plurality of votes is needed to win.
>
> Hopefully this should be decisive, unless the number of Yes and No votes
> matches.
Andrea -
On 5 Jul 2014, at 22:23, Andrea Faulds wrote:
> This RFC attempts to settle the matter once and for all with a straight
> yes/no vote as to whether the name should be PHP 6. Should it pass, the
> matter is settled and we actually have a proper name for this fabled “PHP
> NEXT”. Should it fail
On 06/07/14 02:13, Zeev Suraski wrote:
> I still absolutely think we should bury this until later in the project’s
> lifecycle as our energy **right now** is probably much better spent
> elsewhere.
The problem with that statement is just how do you identify what
material one is looking at relates
On Sat, Jul 5, 2014 at 5:42 PM, Andrea Faulds wrote:
>
> On 6 Jul 2014, at 01:29, Kris Craig wrote:
>
> > I would, however, recommend that Andrea take Zeev's input and create a
> more comprehensive section outlining his arguments in favor of breaking
> from the current convention. Another secti
> -Original Message-
> From: Zeev Suraski [mailto:z...@zend.com]
> Sent: Sunday, July 06, 2014 4:15 AM
> To: 'Andrea Faulds'; 'Christoph Becker'
> Cc: 'Kris Craig'; 'PHP'
> Subject: RE: [PHP-DEV] [RFC] Name of Next Release of PHP
> Argh, I need some sleep. I'll think about it further and respond in the
morning.
I think we have consensus here!
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
:* Sunday, July 06, 2014 3:29 AM
*To:* Andrea Faulds
*Cc:* Zeev Suraski; PHP
*Subject:* Re: [PHP-DEV] [RFC] Name of Next Release of PHP
I would, however, recommend that Andrea take Zeev's input and create a more
comprehensive section outlining his arguments in favor of breaking from the
cu
On 6 Jul 2014, at 02:04, Christoph Becker wrote:
> Andrea Faulds wrote:
>
>> I can see Zeev’s point that 7 is the main other option (though I also
>> think 6.1, or codenames, are possible though unlikely other options).
>> However, I don’t want to call a 50%+1 6/7 vote because it just feels
>>
Andrea Faulds wrote:
> I can see Zeev’s point that 7 is the main other option (though I also
> think 6.1, or codenames, are possible though unlikely other options).
> However, I don’t want to call a 50%+1 6/7 vote because it just feels
> like too narrow of a majority. I suppose if that 6 yes/no vo
On 6 Jul 2014, at 01:29, Kris Craig wrote:
> I would, however, recommend that Andrea take Zeev's input and create a more
> comprehensive section outlining his arguments in favor of breaking from the
> current convention. Another section could be created to outline the other
> side. What we
I would, however, recommend that Andrea take Zeev's input and create a more
comprehensive section outlining his arguments in favor of breaking from the
current convention. Another section could be created to outline the other
side. What we don't want is a situation where Zeev feels compelled to
w
On Sat, Jul 5, 2014 at 4:18 PM, Andrea Faulds wrote:
>
> On 6 Jul 2014, at 00:05, Zeev Suraski wrote:
>
> > I think there's some confusion here.
> >
> > If the next version of PHP is going to be a major one (which is clearly
> > defined in https://wiki.php.net/rfc/releaseprocess), then I believe
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Sunday, July 06, 2014 2:19 AM
> To: Zeev Suraski
> Cc: PHP
> Subject: Re: [PHP-DEV] [RFC] Name of Next Release of PHP
>
>
> On 6 Jul 2014, at 00:05, Zeev Suraski wrote:
>
> >
On 6 Jul 2014, at 00:05, Zeev Suraski wrote:
> I think there's some confusion here.
>
> If the next version of PHP is going to be a major one (which is clearly
> defined in https://wiki.php.net/rfc/releaseprocess), then I believe the
> only two options that were ever raised are PHP 6 and PHP 7.
> I don't want to have a vote with over two choices, I don't think it
would be fair
> (one option could pass without >50% voting for it), and a binary 6/7
choice is
> forcing people's hand. I want it to be simple and straightforward, so
that is why
> it is Yes or No to PHP 6. If people vote no, the
On 5 Jul 2014, at 22:57, Zeev Suraski wrote:
> While I'm not sure whether this isn't a bit premature to have this
> discussion, if we were to have this discussion, the RFC should do a much
> better job at summarizing the discussions we already had in the past.
That’s true. I’ve updated it with
xt version of PHP). Perhaps /rfc/php2015 is a
better choice, or at least /rfc/php.next.name
Thanks! :)
Zeev
> -Original Message-----
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Sunday, July 06, 2014 12:24 AM
> To: PHP
> Subject: [PHP-DEV] [RFC] Name of Next Release of PHP
>
> Goo
Good evening,
I am announcing a rather unorthodox RFC.
With the advent of the phpng and uniform variable syntax RFCs, it looks likely
the next major release of PHP, to succeed the 5.x series, may appear relatively
soon. However, unlike with previous releases of PHP, it is not entirely clear
wh
44 matches
Mail list logo
