Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Sun, Dec 21, 2014 at 04:20:13PM +1100, Pierre Joye wrote: I have hard time to see the benefits of breaking so many codes for that. Has anyone done any benchmarking on the overhead of the internal/hidden convert to lower case of function/... names ? -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Remove deprecated functionality in PHP 7
On 21 December 2014 03:29:54 GMT, Xinchen Hui larue...@php.net wrote: Hey: On Sun, Dec 21, 2014 at 11:25 AM, Andrea Faulds a...@ajf.me wrote: Hey Xinchen, On 21 Dec 2014, at 03:22, Xinchen Hui larue...@php.net wrote: I am strongly against to remove ext/mysql that means, all wordpress users/maintainers, will not able to upgrade to PHP7 without pain. It’d be in PECL and I’m sure every distro would package it, so there’d be no pain. But I also somewhat disagree with removing it, as if it’s in PECL having deprecation notices makes no sense, and we might get rid of them. :( actually, I hope, only hope. we release PHP7 without any big BC break, give people transparent performance improvement.. then we can do minor bc breaks in the second number releases... 7.1 , 7.2 That is more or less the opposite of the agreed release process - obviously we can have *minor* bc breaks later, but putting things off from a 7.0 release to encourage adoption just puts off the problem and risks 7.1 becoming a repeat of 5.3/5.4 in terms of adoption. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Remove deprecated functionality in PHP 7
we release PHP7 without any big BC break, give people transparent performance improvement.. then we can do minor bc breaks in the second number releases... 7.1 , 7.2 That is more or less the opposite of the agreed release process - obviously we can have *minor* bc breaks later, but putting things off from a 7.0 release to encourage adoption just puts off the problem and risks 7.1 becoming a repeat of 5.3/5.4 in terms of adoption. Right - major versions are for major changes. Minor versions are in bc hell. Actually, even the ext/mysql developer folk are not very happy with ext/mysql. Let me quote a mail from 12/2012 Adam Harvey I ended up leaving the vote open for a couple of extra days (been a busy week), but I've now closed the ext/mysql deprecation vote. The full results are at https://wiki.php.net/rfc/mysql_deprecation — the short version is that the final vote was 25-12 in favour of deprecation in PHP 5.5. This made the second question moot, but for the record, the result there was 26-12 in favour of option (a) (deprecation in PHP 5.6 if not in PHP 5.5). In the official Oracle mysql courses, we tell people about mysqlnd, mysqli and PDO Mysql. We tell them to get rid of ext/mysql related code - and not just since yesterday. I know this extension also runs (sort of) with mariadb. But so do others. It's time to say goodbye. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: [RFC] Remove deprecated functionality in PHP 7
On 21 December 2014 03:49:49 GMT, Xinchen Hui larue...@php.net wrote: Hey: On Sun, Dec 21, 2014 at 11:43 AM, Pierre Joye pierre@gmail.com wrote: On Dec 21, 2014 10:23 AM, Xinchen Hui larue...@php.net wrote: Hey: I am strongly against to remove ext/mysql that means, all wordpress users/maintainers, will not able to upgrade to PHP7 without pain. https://make.wordpress.org/core/2014/04/07/mysql-in-wordpress-3-9/ Basically wp and mysql are wrong arguments. we have upgrade issues, they also have that.. I know lots of sites are based on old version wordpress, and they did lot's of custom developing on it.. they will not able to upgrade to any new wordpress.. So your concern is for people who are willing and able to upgrade to PHP 7, unable to upgrade Wordpress, and unable to install a PECL extension which will almost certainly be available as a binary package from their Linux distro? Sorry, but that seems like a rather specific group to base policy on. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On 20 December 2014 22:44:24 GMT, Alain Williams a...@phcomp.co.uk wrote: Fixing this would require a lot of work as well as some way of determining what character encoding the source file was written in ... different includes might have different encodings. We recently talked about a way of specifying source file encoding and decided that it was not something to look at now (IIRC). I haven't read the whole thread yet, so apologies if someone's mentioned this already, but far from being a rejected feature, specifying source file encoding is already possible, using declare(encoding=...) The problem is what to do with that information: presumably, identifiers would need to be converted to an internal encoding (prob utf8), case folded, and normalised (in the Unicode sense of that term). Ideally, this would happen during compilation and stored appropriately in the OpCache, but a run-time path for userland strings would also be necessary. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] Consistent type names in error messages
On 20 Dec 2014, at 15:50, Andrea Faulds a...@ajf.me wrote: On 14 Dec 2014, at 18:35, Andrea Faulds a...@ajf.me wrote: I’ve made a patch which makes zend_parse_parameters and userland type hints consistently show “integer” and “float” rather than “long” and “double”: https://github.com/php/php-src/pull/955 I also wrote a GNU sed script which I used to update the tests: https://gist.github.com/TazeTSchnitzel/c0d780466def9f226318 Hi, Is anyone here opposed to this, or should I just merge it? I don’t think it really needs an RFC. It doesn’t break BC. Thanks. Hey, I’ve merged the patch into master, PHP 7 will have consistent type names in its error messages. :) Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Remove deprecated functionality in PHP 7
On Sun, Dec 21, 2014 at 4:22 AM, Xinchen Hui larue...@php.net wrote: Hey: On Sun, Dec 21, 2014 at 1:33 AM, Nikita Popov nikita@gmail.com wrote: On Sat, Oct 11, 2014 at 10:52 PM, Nikita Popov nikita@gmail.com 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_deprecated_functionality_in_php7 I expect many of these are no-brainers (like assigning new by-reference), but other items like removal of ext/mysql may need additional consideration. Unless there are items that are particularly contested, I'd like to handle the bulk of these in a single vote and only have separate votes for ext/ereg and ext/mysql, as these are arguably more intrusive. Thanks, Nikita I'd like to start voting on this sometime soon. I've updated the RFC to include more info on some individual deprecated functionality and also created blocks for individual votes. I've created seven instead of the original three. If you want me to split off some point into an extra vote, please say so. I am strongly against to remove ext/mysql that means, all wordpress users/maintainers, will not able to upgrade to PHP7 without pain. Please take a look at the WordPress version statistics: https://wordpress.org/about/stats/ According to these statistics 72% of the WordPress installations are running on either PHP 5.2 or PHP 5.3. This means that they do not benefit from the quite substantial performance and memory usage improvements that went into PHP 5.4. So, if people aren't willing to upgrade from PHP 5.2/5.3 to PHP 5.4, I don't see how they'd be more interested in PHP 7. And, as already mentioned, WP already supports mysqli since version 3.9, so people who want to use PHP 7 can do so with a reasonably current version of WP. But anyway, I get that not everyone agrees with removing ext/mysql - that's why we're having votes on this kind of stuff ;) Nikita
Re: [PHP-DEV] Re: [RFC] Remove deprecated functionality in PHP 7
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 running on either PHP 5.2 or PHP 5.3. This means that they do not benefit from the quite substantial performance and memory usage improvements that went into PHP 5.4. So, if people aren't willing to upgrade from PHP 5.2/5.3 to PHP 5.4, I don't see how they'd be more interested in PHP 7. I am running PHP 5.3.3 on my servers. Why ? Summary: running newer versions is a lot of effort. I run CentOS 6 so I run the PHP that is packaged for it. While it might be nice to have PHP 5.6 it would involve me in a lot of work (compile from source) and I would need to do that with each new release/patch. As it is I just go 'yum update' and security fixes, ..., are all installed - easy peasy. If I were to upgrade to CentOS 7 (a lot of work - but it is what I put on new ones) I would have PHP 5.4. The RedHat support term is 10 years and will still be in common use until 2020. I like that - putting a server together can be a lot of work; it can do a lot more than just run PHP. If PHP 5.latest were available in EPEL[**] I would look to upgrade to a more modern PHP. EPEL would make use much easier. It will not happen without someone putting the work in ... and it is much more than just compiling the tar ball, there must be patching and testing in the enterprise environment. [**] A place where other RedHat packages live, sometimes more modern versions of packages in the base distribution. http://fedoraproject.org/wiki/EPEL And, as already mentioned, WP already supports mysqli since version 3.9, so people who want to use PHP 7 can do so with a reasonably current version of WP. But anyway, I get that not everyone agrees with removing ext/mysql - that's why we're having votes on this kind of stuff ;) Nikita -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
On 21 Dec 2014, at 16:53, Alain Williams a...@phcomp.co.uk 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 running on either PHP 5.2 or PHP 5.3. This means that they do not benefit from the quite substantial performance and memory usage improvements that went into PHP 5.4. So, if people aren't willing to upgrade from PHP 5.2/5.3 to PHP 5.4, I don't see how they'd be more interested in PHP 7. I am running PHP 5.3.3 on my servers. Why ? Summary: running newer versions is a lot of effort. I run CentOS 6 so I run the PHP that is packaged for it. While it might be nice to have PHP 5.6 it would involve me in a lot of work (compile from source) and I would need to do that with each new release/patch. As it is I just go 'yum update' and security fixes, ..., are all installed - easy peasy. did you hear about RHSCL? http://developerblog.redhat.com/2014/06/04/red-hat-software-collections-rhscl-1-1-now-ga/ it solves this usecase nicely -- Alexey Zakhlestin CTO at Grids.by/you https://github.com/indeyets PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
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=%28software%29|%28collections%29 SCL 1.1 is supposed to give me PHP 5.5, but I cannot see it. it solves this usecase nicely I don't think so --- please show me that I am wrong. Debian testing is better it is on PHP 5.6.2 Debian stable is on PHP 5.4.35 But my point remains: many people stick with what comes with the operating system distribution. Showing them easy ways of upgrading and staying (security) patched might help. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] Consistent type names in error messages
On 21 Dec 2014 13:25, Andrea Faulds a...@ajf.me wrote: On 20 Dec 2014, at 15:50, Andrea Faulds a...@ajf.me wrote: On 14 Dec 2014, at 18:35, Andrea Faulds a...@ajf.me wrote: I’ve made a patch which makes zend_parse_parameters and userland type hints consistently show “integer” and “float” rather than “long” and “double”: https://github.com/php/php-src/pull/955 I also wrote a GNU sed script which I used to update the tests: https://gist.github.com/TazeTSchnitzel/c0d780466def9f226318 Hi, Is anyone here opposed to this, or should I just merge it? I don’t think it really needs an RFC. It doesn’t break BC. Thanks. Hey, I’ve merged the patch into master, PHP 7 will have consistent type names in its error messages. :) Thanks for the patch and the other contribs you've been doing lately. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On 21 Dec 2014, at 10:32 am, Kevin Israel pleasest...@live.com wrote: On 12/20/2014 05:16 PM, Paul Dragoonis wrote: It's too big of a BC change firstly. Secondly it has no language benefit or developer benefit. Are you sure? Autoloading schemes such as PSR-4 derive pathnames from class names without converting them to lowercase. If case mismatches go undetected and unreported, a project might work on a developer's Windows desktop (case-insensitive) yet not when uploaded to a Linux web server (case-sensitive). Or when an object instantiation or a static method call using the correct case is removed from the code, a later call using the incorrect case might break. Backward compatibility is perhaps a good reason to not make this change. However, I would like to see at least an option to report case mismatches in class names as E_STRICT errors and possibly a way to disable that for specific files or classes when necessary. On 20 Dec 2014 22:01, F N Laupretre nf.laupre...@yahoo.fr wrote: I would like to propose that namespaces, functions, and classes become case-sensitive (constants are already case-sensitive). Actually, I never understood why they are case-insensitive. Even if the performance gain is negligible, I think it could be the right time to question this. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php +1 on E_STRICT warning for case mismatch on class names. Also +1 on eventual case sensitivity for userland class names. Not convinced the rest is worth it. The insensitivity makes code brittle. Sometimes the same code will run fine, and other times it breaks depending on what lines triggered the auto loader. If you instantiate a Foo instance first, then instantiate a new foo, the code runs fine, but if you try to instantiate a new foo first, we get a fatal error. Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
Hey, On 21 Dec 2014, at 23:33, David Muir davidkm...@gmail.com wrote: The insensitivity makes code brittle. Sometimes the same code will run fine, and other times it breaks depending on what lines triggered the auto loader. If you instantiate a Foo instance first, then instantiate a new foo, the code runs fine, but if you try to instantiate a new foo first, we get a fatal error. I’d say that’s not the fault of insensitivity, but the fault of poorly-written autoloaders. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On 22 December 2014 at 01:43, Andrea Faulds a...@ajf.me wrote:
Hey,
On 21 Dec 2014, at 23:33, David Muir davidkm...@gmail.com wrote:
The insensitivity makes code brittle. Sometimes the same code will run
fine, and other times it breaks depending on what lines triggered the auto
loader. If you instantiate a Foo instance first, then instantiate a new
foo, the code runs fine, but if you try to instantiate a new foo first, we
get a fatal error.
I’d say that’s not the fault of insensitivity, but the fault of
poorly-written autoloaders.
I'd like to know if there's an autoloader that handles case sensitivity
without O(2^n) stat calls worst-case scenario (N being namespace/class name
parts chars).
A stricts standards warning in case of type sensitivity issues after a
class with the same was already loaded would make a lot of sense:
class Foo {}
$foo = new Foo;
$bar = ($foo instanceof foo); // stricts standards
Same goes for type-hints in methods, as those may break reflection (which
triggers autoloading).
Greets,
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On 22 Dec 2014, at 00:50, Marco Pivetta ocram...@gmail.com wrote: On 22 December 2014 at 01:43, Andrea Faulds a...@ajf.me wrote: Hey, On 21 Dec 2014, at 23:33, David Muir davidkm...@gmail.com wrote: The insensitivity makes code brittle. Sometimes the same code will run fine, and other times it breaks depending on what lines triggered the auto loader. If you instantiate a Foo instance first, then instantiate a new foo, the code runs fine, but if you try to instantiate a new foo first, we get a fatal error. I’d say that’s not the fault of insensitivity, but the fault of poorly-written autoloaders. I'd like to know if there's an autoloader that handles case sensitivity without O(2^n) stat calls worst-case scenario (N being namespace/class name parts chars). Yes. Those running on Windows or OS X (both use case-insensitive filesystems by default), those that convert the class name to lowercase, those that error on non-lowercase class names, etc. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On 22 December 2014 at 01:52, Andrea Faulds a...@ajf.me wrote: On 22 Dec 2014, at 00:50, Marco Pivetta ocram...@gmail.com wrote: On 22 December 2014 at 01:43, Andrea Faulds a...@ajf.me wrote: Hey, On 21 Dec 2014, at 23:33, David Muir davidkm...@gmail.com wrote: The insensitivity makes code brittle. Sometimes the same code will run fine, and other times it breaks depending on what lines triggered the auto loader. If you instantiate a Foo instance first, then instantiate a new foo, the code runs fine, but if you try to instantiate a new foo first, we get a fatal error. I’d say that’s not the fault of insensitivity, but the fault of poorly-written autoloaders. I'd like to know if there's an autoloader that handles case sensitivity without O(2^n) stat calls worst-case scenario (N being namespace/class name parts chars). Yes. Those running on Windows or OS X (both use case-insensitive filesystems by default), Except that nobody I know of runs production on a case-insensitive filesystem. those that convert the class name to lowercase, those that error on non-lowercase class names, etc. That's an interesting idea to be honest: could be brought up in the composer mailing list, I'd say. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On 22 Dec 2014, at 03:58, Pierre Joye pierre@gmail.com wrote: On Dec 22, 2014 8:03 AM, Marco Pivetta ocram...@gmail.com wrote: On 22 December 2014 at 01:52, Andrea Faulds a...@ajf.me wrote: On 22 Dec 2014, at 00:50, Marco Pivetta ocram...@gmail.com wrote: Except that nobody I know of runs production on a case-insensitive filesystem. I know a lot, really a lot. Yeah, I think it’s too easy to forget that not everyone’s using something Unix-like… a lot of people use Windows Server! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
Development should also be a consideration, I see a lot of developers using Windows for local development (even on the irc channels). These are the same ones who are, in my experience, less likely to be aware of solutions like Vagrant just as much as the subtleties of case sensitivity across operating systems. Mike Dugan Sent from my iPhone On Dec 21, 2014, at 11:00 PM, Andrea Faulds a...@ajf.me wrote: On 22 Dec 2014, at 03:58, Pierre Joye pierre@gmail.com wrote: On Dec 22, 2014 8:03 AM, Marco Pivetta ocram...@gmail.com wrote: On 22 December 2014 at 01:52, Andrea Faulds a...@ajf.me wrote: On 22 Dec 2014, at 00:50, Marco Pivetta ocram...@gmail.com wrote: Except that nobody I know of runs production on a case-insensitive filesystem. I know a lot, really a lot. Yeah, I think it’s too easy to forget that not everyone’s using something Unix-like… a lot of people use Windows Server! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Mon, Dec 22, 2014 at 3:05 PM, Mike Dugan m...@mjdugan.com wrote: Development should also be a consideration, I see a lot of developers using Windows for local development (even on the irc channels). These are the same ones who are, in my experience, less likely to be aware of solutions like Vagrant just as much as the subtleties of case sensitivity across operating systems. I think we coul be more realistic here. In my opinion the pains introduced by such a change does not match with any possible gains. Many areas affect the request time badly (IOs, mem, etc), I do not see case insensitivity as one, even if it may look very bad if a simple small script is taken as example of the slowdown (obviously worst case). I am not saying discussing that is bad, but it may not be the most important thing to spend time on :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Mon, Dec 22, 2014 at 12:35 PM, Pierre Joye pierre@gmail.com wrote: On Mon, Dec 22, 2014 at 3:05 PM, Mike Dugan m...@mjdugan.com wrote: Development should also be a consideration, I see a lot of developers using Windows for local development (even on the irc channels). These are the same ones who are, in my experience, less likely to be aware of solutions like Vagrant just as much as the subtleties of case sensitivity across operating systems. I think we coul be more realistic here. In my opinion the pains introduced by such a change does not match with any possible gains. Many areas affect the request time badly (IOs, mem, etc), I do not see case insensitivity as one, even if it may look very bad if a simple small script is taken as example of the slowdown (obviously worst case). I am not saying discussing that is bad, but it may not be the most important thing to spend time on :) Agree.. I am afraid that will never happen(case-sesentive class/function name) in the whole php life thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
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 with the operating system distribution. And they will switch when the OS Vendor switches. This is completely separate from what these versions do contain. BTW, if you need latest PHP rpm's for distribution $foo, you will probably find them on open build service. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
On Dec 22, 2014 12:27 PM, Ralf Lang l...@b1-systems.de 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/ But my point remains: many people stick with what comes with the operating system distribution. And they will switch when the OS Vendor switches. This is completely separate from what these versions do contain. BTW, if you need latest PHP rpm's for distribution $foo, you will probably find them on open build service. Or Remi's repo. Best thing ever :) -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
