On 12/08/2015 08:32 AM, Lester Caine wrote:
On 08/12/15 02:23, Rasmus Lerdorf wrote:
Ah, I just checked. You have no opcache at all in your PHP 7 setup. And you
have eaccelerator configured for PHP 5. So an opcode cached PHP 5 is only 10%
faster than a completely unaccelerated PHP 7. That's pr
Den 2015-12-08 kl. 16:00, skrev Adam Howard:
The EOL (end of life) date does influence people. True, not everyone will
simply jump ship upon EOL. But it is still has a significant enough
influence on adoption and urgency in general. Especially toward new
development projects or new releases in
hi,
On Wed, Dec 9, 2015 at 2:51 AM, Adam Howard wrote:
> #3 all the way. Extending support only extends the excuse of poor habits
> and encourages those habits.
Same here.
However, if I have to choose something I would like to understand why
all of a sudden December 31 become a valid date. It
#3 all the way. Extending support only extends the excuse of poor habits
and encourages those habits.
On Tue, Dec 8, 2015 at 2:13 PM, Scott Arciszewski
wrote:
> On Tue, Dec 8, 2015 at 10:14 AM, Zeev Suraski wrote:
>
> > Following the initial discussion, I prepared an RFC that proposes to
> ext
On Tue, Dec 8, 2015 at 10:14 AM, Zeev Suraski wrote:
> Following the initial discussion, I prepared an RFC that proposes to extend
> the support periods for PHP 5.6:
>
>
>
> https://wiki.php.net/rfc/php56timeline
>
>
>
> Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any glaring
>
Zeev,
On Tue, Dec 8, 2015 at 1:15 PM, Zeev Suraski wrote:
>> -Original Message-
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Tuesday, December 08, 2015 6:09 PM
>> To: Zeev Suraski
>> Cc: PHP internals
>> Subject: Re: [PHP-DEV] RFC: PHP 5.6 Support Timeline
>>
>> Zeev,
>>
> BTW, to be clear, this is really about "PHP 5 Support Timeline"
>
> (so not about a "minor" version timeline, but really about a "major"
> version one, the reason why I will +1 option #1)
That’ a very good point also raised by Ferenc in his review. I amended it
further and actually changed the
> -Original Message-
> From: Derick Rethans [mailto:der...@php.net]
> Sent: Tuesday, December 08, 2015 6:11 PM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] RFC: PHP 5.6 Support Timeline
>
> I think you're making the voting too complicated :-) In the case that I
> don't
>
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Tuesday, December 08, 2015 6:09 PM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] RFC: PHP 5.6 Support Timeline
>
> Zeev,
>
> On Tue, Dec 8, 2015 at 10:14 AM, Zeev Suraski wrote:
> > Followin
See my suggestion to split it into two separate votes ;)
> On 08.12.2015, at 17:11, Derick Rethans wrote:
>
> On Tue, 8 Dec 2015, Zeev Suraski wrote:
>
>> Following the initial discussion, I prepared an RFC that proposes to extend
>> the support periods for PHP 5.6:
>>
>> https://wiki.php.net/
On Tue, 8 Dec 2015, Zeev Suraski wrote:
> Following the initial discussion, I prepared an RFC that proposes to extend
> the support periods for PHP 5.6:
>
> https://wiki.php.net/rfc/php56timeline
>
> Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any glaring
> omissions.
>
> Let
Zeev,
On Tue, Dec 8, 2015 at 10:14 AM, Zeev Suraski wrote:
> Following the initial discussion, I prepared an RFC that proposes to extend
> the support periods for PHP 5.6:
>
>
>
> https://wiki.php.net/rfc/php56timeline
>
>
>
> Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any glar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 08/12/2015 16:14, Zeev Suraski a écrit :
> Following the initial discussion, I prepared an RFC that proposes
> to extend the support periods for PHP 5.6:
>
>
>
> https://wiki.php.net/rfc/php56timeline
Thanks for the work.
BTW, to be clear, thi
Am 08.12.2015 um 16:14 schrieb Zeev Suraski:
> I prepared an RFC that proposes to extend the support periods for PHP 5.6
Thank you for your work on this RFC, Zeev.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> -Original Message-
> From: David Zuelke [mailto:d...@heroku.com]
> Sent: Tuesday, December 08, 2015 5:19 PM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] RFC: PHP 5.6 Support Timeline
>
> It just occurred to me (too late :D sorry Zeev) that it might make sense
> to
> spl
It just occurred to me (too late :D sorry Zeev) that it might make sense to
split this into two RFCs:
- to define the active support end date for 5.6 (e.g. "2016-08-28" or
"2016-12-02" or "2016-12-31")
- to define the security support end date for 5.6, and specify that relative to
the active su
Following the initial discussion, I prepared an RFC that proposes to extend
the support periods for PHP 5.6:
https://wiki.php.net/rfc/php56timeline
Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any glaring
omissions.
Let the discussion continue…
Zeev
On 08.12.2015, at 13:32, Lester Caine wrote:
> Bottom line is that given the real world loading on my sites, the
> differences are probably in the noise of network transit times so not
> impressive at all :(
... or you have a bunch of very slow queries in there that are eating up the
majority o
The EOL (end of life) date does influence people. True, not everyone will
simply jump ship upon EOL. But it is still has a significant enough
influence on adoption and urgency in general. Especially toward new
development projects or new releases in general that are less likely to
code with supp
Results for project PHP master, build date 2015-12-08 12:32:22+02:00
commit: c58b0cb4ceb26d96c2088b80e98c6cbc6b3971bd
revision date: 2015-12-08 12:47:05+03:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping
2, LLC 45 MB
mem
Hi,
- Mail original -
> De: "Anatol Belski"
>
> - 7.0.1RC1 on 10th December
By the way, could someone merge https://github.com/php/php-src/pull/1602 for
RC1 ?
Thanks
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, Dec 8, 2015 at 1:32 PM, Lester Caine wrote:
> On 08/12/15 02:23, Rasmus Lerdorf wrote:
> > Ah, I just checked. You have no opcache at all in your PHP 7 setup. And
> you have eaccelerator configured for PHP 5. So an opcode cached PHP 5 is
> only 10% faster than a completely unaccelerated P
Hi Ferenc,
> -Original Message-
> From: tyr...@gmail.com [mailto:tyr...@gmail.com] On Behalf Of Ferenc
> Kovacs
> Sent: Tuesday, December 8, 2015 2:41 PM
> To: Julien Pauli
> Cc: Remi Collet ; PHP Internals ;
> Anatol Belsky ; Stanislav Malyshev
> Subject: Re: [PHP-DEV] Re: PHP 7.0.1 sch
On Tue, Dec 8, 2015 at 1:26 PM, Julien Pauli wrote:
> On Tue, Dec 8, 2015 at 1:04 PM, Remi Collet wrote:
> > Le 08/12/2015 12:36, Anatol Belski a écrit :
> >> Yeah, particularly our release schedule collides with many holidays
> this year. For a security release a holiday time is obviously very
On 08/12/15 02:23, Rasmus Lerdorf wrote:
> Ah, I just checked. You have no opcache at all in your PHP 7 setup. And you
> have eaccelerator configured for PHP 5. So an opcode cached PHP 5 is only 10%
> faster than a completely unaccelerated PHP 7. That's pretty damn impressive!
Gallery page with
On Tue, Dec 8, 2015 at 1:04 PM, Remi Collet wrote:
> Le 08/12/2015 12:36, Anatol Belski a écrit :
>> Yeah, particularly our release schedule collides with many holidays this
>> year. For a security release a holiday time is obviously very bad.
>
> +1
>
> Our Release Process state:
>
> " A
On Sun, 2015-12-06 at 15:17 -0800, Stanislav Malyshev wrote:
> Sufficient for what? It is a hard fact that people still run 5.3
> version. In fact, 2/3 of sites run EOLed versions. You can always say
> they have only themselves to blame, but then I'm not sure what
> "sufficient" means. Unless adopt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 08/12/2015 13:04, Remi Collet a écrit :
> Perhaps we should consider new release on
>
> " 1st thursday of the month "
>
> (It seems every year, Christmas is end of month ;)
As Thanksgiving and Dec 31th.
-BEGIN PGP SIGNATURE-
Version: Gn
Le 08/12/2015 12:36, Anatol Belski a écrit :
> Yeah, particularly our release schedule collides with many holidays this
> year. For a security release a holiday time is obviously very bad.
+1
Our Release Process state:
" At least one release per month, more at wish "
Perhaps we should
Hi,
> -Original Message-
> From: julienpa...@gmail.com [mailto:julienpa...@gmail.com] On Behalf Of
> Julien Pauli
> Sent: Tuesday, December 8, 2015 11:26 AM
> To: Anatol Belski
> Cc: PHP Internals ; Ferenc Kovacs ;
> Remi Collet
> Subject: Re: PHP 7.0.1 scheduling
>
> On Sat, Dec 5, 201
Hi,
- Mail original -
> De: "Dustin Wheeler"
> friendship protect the original class from unwarranted access. The
> common
> expression of these properties is something like: "Just because I
> grant you
> friendship access to me doesn’t automatically grant your kids access
> to me,
> doe
Hi,
- Mail original -
De: guilhermebla...@gmail.com
> My biggest concern about supporting friend classes is the ability to access
> non-intentional to be accessed code outside of the original class's
> knowledge. This by itself is very dangerous.
That's the opposite : the 'friend' keywor
Hi,
Thanks for this interesting and well-documented message.
When looking at the history about class friendship, you may have seen that the
concept was globally rejected in favor of Guilherme's project of
'package-privacy'. I personnally think friend classes are a different and more
powerful
On Sat, Dec 5, 2015 at 10:02 PM, Anatol Belski wrote:
> Hi,
>
> FYI. Given the shift of the 7.0.0 release date by one week off the usual two
> weeks release schedule, 7.0.1RC1 is planned for December 10th and to be
> tagged on December 8th. This serves two goals
>
> - there are already some bug f
Hi Sean,
The PR has been merged into master.
Please update the RFC accordingly.
Thanks to Nikita and Xinchen for code review and suggestions.
Thanks. Dmitry.
On Mon, Dec 7, 2015 at 11:38 AM, Dmitry Stogov wrote:
> Hi Nikita,
>
> Thanks for code review.
> All the reported issues should be fixed
35 matches
Mail list logo
