On Mon, Dec 22, 2014 at 10:17 AM, Alain Williams wrote:
> On Mon, Dec 22, 2014 at 05:04:23PM +1100, Pierre Joye wrote:
>
> > Or Remi's repo. Best thing ever :)
>
> Oh - that is news for me!
>
> http://remi.check-update.co.uk/
>
> Could I suggest that things like this are linked to from here:
>
>
On Mon, Dec 22, 2014 at 05:04:23PM +1100, Pierre Joye wrote:
> Or Remi's repo. Best thing ever :)
Oh - that is news for me!
http://remi.check-update.co.uk/
Could I suggest that things like this are linked to from here:
http://uk1.php.net/downloads.php
Even if you feel that there must be a dis
On Dec 22, 2014 12:27 PM, "Ralf Lang" wrote:
>
> On 21.12.2014 16:12, Alain Williams wrote:
> > On Sun, Dec 21, 2014 at 05:23:53PM +0300, Alexey Zakhlestin wrote:
> >
> >> did you hear about RHSCL?
> >>
http://developerblog.redhat.com/2014/06/04/red-hat-software-collections-rhscl-1-1-now-ga/
> >
>
On 21.12.2014 16:12, Alain Williams wrote:
> On Sun, Dec 21, 2014 at 05:23:53PM +0300, Alexey Zakhlestin wrote:
>
>> did you hear about RHSCL?
>> http://developerblog.redhat.com/2014/06/04/red-hat-software-collections-rhscl-1-1-now-ga/
>
> But my point remains: many people stick with what comes w
On Sun, Dec 21, 2014 at 05:23:53PM +0300, Alexey Zakhlestin wrote:
> did you hear about RHSCL?
> http://developerblog.redhat.com/2014/06/04/red-hat-software-collections-rhscl-1-1-now-ga/
Yes. That gives me PHP 5.4:
http://wiki.centos.org/AdditionalResources/Repositories/SCL?highlight=%28sof
> On 21 Dec 2014, at 16:53, Alain Williams wrote:
>
> On Sun, Dec 21, 2014 at 02:30:28PM +0100, Nikita Popov wrote:
>
>
>> Please take a look at the WordPress version statistics:
>> https://wordpress.org/about/stats/
>>
>> According to these statistics 72% of the WordPress installations are
>
On Tue, Oct 14, 2014 at 4:00 PM, Johannes Schlüter
wrote:
> On Mon, 2014-10-13 at 23:06 -0700, Stas Malyshev wrote:
>> - drop incompatible $this context calls (probably seriously messed up
>> code)
>
> Before removing: Could anybody check whether this breaks PEAR (incl.
> `pecl install`) I don't k
On Mon, 2014-10-13 at 23:06 -0700, Stas Malyshev wrote:
> - drop incompatible $this context calls (probably seriously messed up
> code)
Before removing: Could anybody check whether this breaks PEAR (incl.
`pecl install`) I don't know how much PHP 4 legacy which required such
tricks is still in the
Hi!
I would say we should choose according to the following criteria:
1. Is anybody likely to use it, and if so, will dropping it impede
adoption significantly?
2. Would using it get you into some trouble you can't see easily?
3. How easy it's to detect that something is broken due to BC change?
Hi!
>> We have chosen to deprecate features, including ext/mysql. If we now
>> decide not to remove some of them for 7, we may just remove the
>> deprecation flag as we are going to support them for the next decade
>> as well, whether we like it or not.
I don't see how this follows. We may keep t
On Oct 13, 2014 8:08 PM, "Jan Ehrhardt" wrote:
>
> Pierre Joye in php.internals (Mon, 13 Oct 2014 14:21:24 +0200):
> >On Oct 13, 2014 7:10 PM, "Jan Ehrhardt" wrote:
> >>
> >> In the ext/mysql case this will be a bit uncomfortable. If you compile
> >> PHP --with-mysql=mysqlnd the mysqlnd-part is i
Pierre Joye in php.internals (Mon, 13 Oct 2014 14:21:24 +0200):
>On Oct 13, 2014 7:10 PM, "Jan Ehrhardt" wrote:
>>
>> In the ext/mysql case this will be a bit uncomfortable. If you compile
>> PHP --with-mysql=mysqlnd the mysqlnd-part is in core, while a part of
>> the functionality of ext/mysql is
On Mon, 2014-10-13 at 14:10 +0200, Jan Ehrhardt wrote:
> In the ext/mysql case this will be a bit uncomfortable. If you compile
> PHP --with-mysql=mysqlnd the mysqlnd-part is in core, while a part of
> the functionality of ext/mysql is used. What if mysqlnd drifts away from
> supporting ext/mysql?
On Oct 13, 2014 7:10 PM, "Jan Ehrhardt" wrote:
>
> Dmitry Stogov in php.internals (Mon, 13 Oct 2014 14:29:06 +0400):
> >Note, that once we move extension outside of main source tree, only
> >extension maintainers (if any) will support them.
>
> In the ext/mysql case this will be a bit uncomfortabl
Dmitry Stogov in php.internals (Mon, 13 Oct 2014 14:29:06 +0400):
>Note, that once we move extension outside of main source tree, only
>extension maintainers (if any) will support them.
In the ext/mysql case this will be a bit uncomfortable. If you compile
PHP --with-mysql=mysqlnd the mysqlnd-part
Note, that once we move extension outside of main source tree, only
extension maintainers (if any) will support them.
According to the voting process, I think it makes sense to vote for each
feature separately.
Thanks. Dmitry.
On Sun, Oct 12, 2014 at 4:13 AM, Rasmus Lerdorf wrote:
> > On Oc
On Mon, Oct 13, 2014 at 8:51 AM, Pierre Joye wrote:
> On Sun, Oct 12, 2014 at 12:36 PM, Zeev Suraski wrote:
>
>>
>> For the record, I don't feel strongly about # comments, but I do think that
>> we should have good reasons to actually *remove* features that are better
>> than "this is how it's do
On 13 October 2014 08:06:16 GMT+01:00, Lester Caine wrote:
>On 13/10/14 01:35, Rowan Collins wrote:
>>> Because ini files use ; for comments and not #.
>>
>> - The behaviour of # as comments in earlier versions seems to have
>been
>> a side-effect of something else, rather than a deliberate featu
On 13/10/14 01:35, Rowan Collins wrote:
>> Because ini files use ; for comments and not #.
>
> - The behaviour of # as comments in earlier versions seems to have been
> a side-effect of something else, rather than a deliberate feature. In
> fact, it was possible to have a key starting with #, but
On Sun, Oct 12, 2014 at 12:36 PM, Zeev Suraski wrote:
>
> For the record, I don't feel strongly about # comments, but I do think that
> we should have good reasons to actually *remove* features that are better
> than "this is how it's done". Valid reasons can be performance penalties of
> keepin
On 12/10/2014 11:11, Nikita Popov wrote:
For example, things like this:
>
> # style comments in ini files (since PHP 5.3)
>
>I don't think we should remove at all (or why is this even deprecated?!
>
Because ini files use ; for comments and not #.
I was curious enough about this to dig into so
Hi Andrea,
> Allowing # for comments stops you from using # in string property values.
>
> Though I'm not sure why you'd need to.
That will be the case for any character to use for comments. Uses ;
for comments will stop you from using it in values.
Regards.
--
Yannick K.
--
PHP Internals - P
On 12 Oct 2014, at 11:36, Zeev Suraski wrote:
> For the record, I don't feel strongly about # comments, but I do think that
> we should have good reasons to actually *remove* features that are better
> than "this is how it's done". Valid reasons can be performance penalties of
> keeping the fea
> -Original Message-
> From: Nikita Popov [mailto:nikita@gmail.com]
> Sent: Sunday, October 12, 2014 1:11 PM
> To: Derick Rethans
> Cc: PHP internals
> Subject: Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
>
> On Sun, Oct 12, 2014 at 9:56 A
I think there should be a little bit more voting "options" - or rather
categories.
For example, things like this:
# style comments in ini files (since PHP 5.3)
I don't think we should remove at all (or why is this even deprecated?!
Because ini files use ; for comments and not #.
Nikita
On Sun, Oct 12, 2014 at 9:56 AM, Derick Rethans wrote:
> On Sat, 11 Oct 2014, Nikita Popov wrote:
>
> > Hi internals!
> >
> > We currently have a number of deprecated features, which we likely want
> to
> > remove in PHP 7. I've created a tracking RFC listing deprecated
> > functionality (if I mi
On Oct 12, 2014 12:54 AM, "Derick Rethans" wrote:
>
> On Sat, 11 Oct 2014, Kris Craig wrote:
>
> > On Oct 11, 2014 1:52 PM, "Nikita Popov" wrote:
> > >
> > > We currently have a number of deprecated features, which we likely
> > > want to remove in PHP 7. I've created a tracking RFC listing
> > >
On 12/10/14 01:13, Rasmus Lerdorf wrote:
> Keep in mind though that it would be mostly symbolic. The majority of users
> get their PHP and extensions from distros. And distros have been separating
> out core-bundled extensions for a decade now. Users have absolutely no idea
> whether their php-m
On Sat, 11 Oct 2014, Nikita Popov wrote:
> Hi internals!
>
> We currently have a number of deprecated features, which we likely want to
> remove in PHP 7. I've created a tracking RFC listing deprecated
> functionality (if I missed something, please tell):
>
> https://wiki.php.net/rfc/remove_
On Sat, 11 Oct 2014, Kris Craig wrote:
> On Oct 11, 2014 1:52 PM, "Nikita Popov" wrote:
> >
> > We currently have a number of deprecated features, which we likely
> > want to remove in PHP 7. I've created a tracking RFC listing
> > deprecated functionality (if I missed something, please tell):
> On Oct 11, 2014, at 16:47, Kris Craig wrote:
>
>> On Oct 11, 2014 1:52 PM, "Nikita Popov" wrote:
>>
>> Hi internals!
>>
>> We currently have a number of deprecated features, which we likely want to
>> remove in PHP 7. I've created a tracking RFC listing deprecated
>> functionality (if I miss
On Oct 11, 2014 1:52 PM, "Nikita Popov" wrote:
>
> Hi internals!
>
> We currently have a number of deprecated features, which we likely want to
> remove in PHP 7. I've created a tracking RFC listing deprecated
> functionality (if I missed something, please tell):
>
> https://wiki.php.net/rfc/r
Hi internals!
We currently have a number of deprecated features, which we likely want to
remove in PHP 7. I've created a tracking RFC listing deprecated
functionality (if I missed something, please tell):
https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7
I expect many of these
33 matches
Mail list logo
