According to our docs/internal checks, our min php version is 5.3.3. However as of 6e283d394f31, MediaWiki doesn't work with php 5.3.3 (You aren't allowed to implement an interface using an abstract method, on that version of PHP so you get "Fatal error: Can't inherit abstract function IDatabase::getType() (previously declared abstract in DatabaseBase) in git/includes/db/Database.php on line 32").
Is it time we up'd our version requirements (And does anyone know if that would affect lots of third parties?) Or should that change be reverted?
--bawolff
On 07/19/2015 04:35 AM, bawolff wrote:
According to our docs/internal checks, our min php version is 5.3.3. However as of 6e283d394f31, MediaWiki doesn't work with php 5.3.3 (You aren't allowed to implement an interface using an abstract method, on that version of PHP so you get "Fatal error: Can't inherit abstract function IDatabase::getType() (previously declared abstract in DatabaseBase) in git/includes/db/Database.php on line 32").
This was introduced in https://gerrit.wikimedia.org/r/#/c/222188/, which we could work around by removing the abstract definitions.
-- Legoktm
On Sun, Jul 19, 2015 at 4:35 AM, bawolff bawolff+wn@gmail.com wrote:
According to our docs/internal checks, our min php version is 5.3.3. However as of 6e283d394f31, MediaWiki doesn't work with php 5.3.3 (You aren't allowed to implement an interface using an abstract method, on that version of PHP so you get "Fatal error: Can't inherit abstract function IDatabase::getType() (previously declared abstract in DatabaseBase) in git/includes/db/Database.php on line 32").
Is it time we up'd our version requirements (And does anyone know if that would affect lots of third parties?) Or should that change be reverted?
Some WMF production hosts are still on PHP 5.3.10 so as Tim pointed out last spring [0] we shouldn't drop 5.3 support until after the entirety of the WMF server fleet are all switched over to HHVM or at least a newer version of PHP5. Aaron's patch probably needs to be either reverted or amended to remove the incompatible change.
I'd really like us to switch to PHP 5.5 as the minimum supported version sooner rather than later but as I once heard on irc, it would be a bit inconvenient if Wikimedia could not run MediaWiki.
[0]: http://www.gossamer-threads.com/lists/wiki/wikitech/436441#436441
Hi php 5.5 is still probly years from being minium in mediawiki due to so many users use php 5.3 and 5.4. It would be a bigger impact on mediawiki then when we switch to 5.3 from the prevous minium of 5.2.
On Sunday, 19 July 2015, 15:15, Bryan Davis bd808@wikimedia.org wrote:
On Sun, Jul 19, 2015 at 4:35 AM, bawolff bawolff+wn@gmail.com wrote:
According to our docs/internal checks, our min php version is 5.3.3. However as of 6e283d394f31, MediaWiki doesn't work with php 5.3.3 (You aren't allowed to implement an interface using an abstract method, on that version of PHP so you get "Fatal error: Can't inherit abstract function IDatabase::getType() (previously declared abstract in DatabaseBase) in git/includes/db/Database.php on line 32").
Is it time we up'd our version requirements (And does anyone know if that would affect lots of third parties?) Or should that change be reverted?
Some WMF production hosts are still on PHP 5.3.10 so as Tim pointed out last spring [0] we shouldn't drop 5.3 support until after the entirety of the WMF server fleet are all switched over to HHVM or at least a newer version of PHP5. Aaron's patch probably needs to be either reverted or amended to remove the incompatible change.
I'd really like us to switch to PHP 5.5 as the minimum supported version sooner rather than later but as I once heard on irc, it would be a bit inconvenient if Wikimedia could not run MediaWiki.
[0]: http://www.gossamer-threads.com/lists/wiki/wikitech/436441#436441
Hi!
Hi php 5.5 is still probly years from being minium in mediawiki due to so many users use php 5.3 and 5.4.
The users should really seriously consider upgrading. 5.3 is EOL for a year now (which means, not even security fixes for a year) and 5.4 is going EOL in 2 months. If any of these sites are public-facing (and due to the nature of wikis, many of them, to some measure, are), running out-of-support software may not be that good an idea.
On 19 July 2015 at 19:41, Stas Malyshev smalyshev@wikimedia.org wrote:
The users should really seriously consider upgrading. 5.3 is EOL for a year now (which means, not even security fixes for a year) and 5.4 is going EOL in 2 months. If any of these sites are public-facing (and due to the nature of wikis, many of them, to some measure, are), running out-of-support software may not be that good an idea.
If this is all their host provides, however, this will in practice lead only to never-updated MediaWiki running on never-updated PHP.
- d.
<quote name="David Gerard" date="2015-07-20" time="12:04:55 +0100">
If this is all their host provides, however, this will in practice lead only to never-updated MediaWiki running on never-updated PHP.
Not much anyone other than the host or the user can do about that. Certainly nothing we (MW devs and/or WMF) can.
On 20 July 2015 at 17:03, Greg Grossmeier greg@wikimedia.org wrote:
<quote name="David Gerard" date="2015-07-20" time="12:04:55 +0100">
If this is all their host provides, however, this will in practice lead only to never-updated MediaWiki running on never-updated PHP.
Not much anyone other than the host or the user can do about that. Certainly nothing we (MW devs and/or WMF) can.
What I'm answering is the proposal that removing support for PHP 5.3 will motivate the user to upgrade their PHP, when that isn't the case.
I recall this has been the conclusion reached on this list previously - that this will cause problems for MW out in the world, and gain it an unwarranted reputation for insecurity as un-upgradeable installations get pwned. Thus, if newer MW still supports older PHP, this results in less pwned MW. The balance is up to you, of course.
- d.
On 07/20/2015 09:18 AM, David Gerard wrote:
What I'm answering is the proposal that removing support for PHP 5.3 will motivate the user to upgrade their PHP, when that isn't the case.
I recall this has been the conclusion reached on this list previously
- that this will cause problems for MW out in the world, and gain it
an unwarranted reputation for insecurity as un-upgradeable installations get pwned. Thus, if newer MW still supports older PHP, this results in less pwned MW. The balance is up to you, of course.
OTOH, if we never bump our version requirements, there's less incentive for hosting providers to upgrade their PHP. [1] has some interesting arguments regarding this.
[1] http://blog.ircmaxell.com/2014/12/on-php-version-requirements.html
-- Legoktm
Just as a counter-argument (and, to be clear, I do support raising our minimum version), just because PHP has EOL'ed a version does not mean that some distributions (esp. Debian, Ubuntu) are not providing additional support and security updates.
If I remember from the last time we had this discussion, it will still be a couple more months before PHP 5.3 is no longer supported by most major distros, and it will be a while before 5.4 is no longer supported.
-- Tyler Romeo https://parent5446.nyc 0x405D34A7C86B42DF
Hi,
On Tue, Jul 21, 2015 at 8:13 AM, Tyler Romeo tylerromeo@gmail.com wrote:
Just as a counter-argument (and, to be clear, I do support raising our minimum version), just because PHP has EOL'ed a version does not mean that some distributions (esp. Debian, Ubuntu) are not providing additional support and security updates.
If I remember from the last time we had this discussion, it will still be a couple more months before PHP 5.3 is no longer supported by most major distros, and it will be a while before 5.4 is no longer supported.
That's true, here's the specific EOL dates for common distros with PHP 5.3
Debian 6.0 is supported until February 2016 and has PHP 5.3.3
Ubuntu 12.04 is supported until April 2017 and has PHP 5.3.10
RHEL 6/Centos is supported until June 2017 (and limited supported until 2020) and has PHP 5.3.3 (but they also provide officially supported 5.4/5.5 packages)
Cheers, Moritz
On Tue, Jul 21, 2015 at 2:44 AM, Moritz Muhlenhoff mmuhlenhoff@wikimedia.org wrote:
Hi,
On Tue, Jul 21, 2015 at 8:13 AM, Tyler Romeo tylerromeo@gmail.com wrote:
Just as a counter-argument (and, to be clear, I do support raising our minimum version), just because PHP has EOL'ed a version does not mean that some distributions (esp. Debian, Ubuntu) are not providing additional support and security updates.
If I remember from the last time we had this discussion, it will still be a couple more months before PHP 5.3 is no longer supported by most major distros, and it will be a while before 5.4 is no longer supported.
That's true, here's the specific EOL dates for common distros with PHP 5.3
Debian 6.0 is supported until February 2016 and has PHP 5.3.3
Ubuntu 12.04 is supported until April 2017 and has PHP 5.3.10
RHEL 6/Centos is supported until June 2017 (and limited supported until 2020) and has PHP 5.3.3 (but they also provide officially supported 5.4/5.5 packages)
Cheers, Moritz _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
https://wikiapiary.com/w/index.php?title=Special:SearchByProperty&limit=... is also something to keep in mind
--bawolff
<quote name="Moritz Muhlenhoff" date="2015-07-21" time="10:44:59 +0200">
Debian 6.0 is supported until February 2016 and has PHP 5.3.3
Ubuntu 12.04 is supported until April 2017 and has PHP 5.3.10
RHEL 6/Centos is supported until June 2017 (and limited supported until 2020) and has PHP 5.3.3 (but they also provide officially supported 5.4/5.5 packages)
Based on those dates I think we should make the bump sooner than later. Less than a year left for Debian support isn't that long, really.
One thing I forgot to mention: while you're considering Debian and Ubuntu support, make sure to also take into account MediaWiki support.
Even if we upgrade our minimum PHP version now, older versions of MediaWiki with the 5.3 requirement will still be supported and receive security updates. So the only difference will be that people running Debian oldstable will be locked into our older version and not be able to upgrade to bleeding edge MediaWiki, which they probably won't do anyway considering they haven't even upgraded their Debian. :P
-- Tyler Romeo https://parent5446.nyc 0x405D34A7C86B42DF
On Tue, Jul 21, 2015 at 11:27 AM, Tyler Romeo tylerromeo@gmail.com wrote:
One thing I forgot to mention: while you're considering Debian and Ubuntu support, make sure to also take into account MediaWiki support.
Even if we upgrade our minimum PHP version now, older versions of MediaWiki with the 5.3 requirement will still be supported and receive security updates. So the only difference will be that people running Debian oldstable will be locked into our older version and not be able to upgrade to bleeding edge MediaWiki, which they probably won't do anyway considering they haven't even upgraded their Debian. :P
Specifically, 1.23, which is the current LTS (long-term support) release, is supported until May 2017 (so that covers Debian/Ubuntu and almost covers RedHat, but that one provides PHP 5.5 anyway).
The next LTS is due spring 2016 and will be supported until spring 2019 and I don't think we want to get stuck on PHP 5.3 with that one.
On Tue, 21 Jul 2015 22:22:41 +0200, Gergo Tisza gtisza@wikimedia.org wrote:
On Tue, Jul 21, 2015 at 11:27 AM, Tyler Romeo tylerromeo@gmail.com wrote:
Even if we upgrade our minimum PHP version now, older versions of MediaWiki with the 5.3 requirement will still be supported and receive security updates. So the only difference will be that people running Debian oldstable will be locked into our older version and not be able to upgrade to bleeding edge MediaWiki, which they probably won't do anyway considering they haven't even upgraded their Debian. :P
Specifically, 1.23, which is the current LTS (long-term support) release, is supported until May 2017 (so that covers Debian/Ubuntu and almost covers RedHat, but that one provides PHP 5.5 anyway).
The next LTS is due spring 2016 and will be supported until spring 2019 and I don't think we want to get stuck on PHP 5.3 with that one.
Indeed, I think this is a very good argument.
Do we want to do this now? Or do we want to fix the accidentally broken 5.3.3 compatibility for now, and then intentionally break it in a few months?
Should the upcoming MediaWiki 1.26 release be compatibly with 5.3.3?
On Tue, Jul 21, 2015 at 1:22 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Tue, Jul 21, 2015 at 11:27 AM, Tyler Romeo tylerromeo@gmail.com wrote:
One thing I forgot to mention: while you're considering Debian and Ubuntu support, make sure to also take into account MediaWiki support.
Even if we upgrade our minimum PHP version now, older versions of MediaWiki with the 5.3 requirement will still be supported and receive security updates. So the only difference will be that people running
Debian
oldstable will be locked into our older version and not be able to
upgrade
to bleeding edge MediaWiki, which they probably won't do anyway
considering
they haven't even upgraded their Debian. :P
Specifically, 1.23, which is the current LTS (long-term support) release, is supported until May 2017 (so that covers Debian/Ubuntu and almost covers RedHat, but that one provides PHP 5.5 anyway).
The next LTS is due spring 2016 and will be supported until spring 2019 and I don't think we want to get stuck on PHP 5.3 with that one. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I don't have a whole lot to add to this argument, but the above statement rings very true to me. I think it would be a big misstep to continue supporting 5.3 until 2019.
Erik B.
Hi!
What I'm answering is the proposal that removing support for PHP 5.3 will motivate the user to upgrade their PHP, when that isn't the case.
It may not motivate them to upgrade their PHP if their hosting can not provide that, but it will motivate them to upgrade their hosting, if the hosting refuses to upgrade their PHP. Hosting is so commoditized now that I don't believe one can't find a dozen of PHP hosters literally in seconds. And most hosters already support multiple PHP versions anyway.
I recall this has been the conclusion reached on this list previously
- that this will cause problems for MW out in the world, and gain it
an unwarranted reputation for insecurity as un-upgradeable installations get pwned. Thus, if newer MW still supports older PHP, this results in less pwned MW. The balance is up to you, of course.
I have hard time buying this argument. If it were true, the strategy of doing version upgrades and phasing out old version support would not survive, or at least would be very rare among software vendors, while in fact most software platform vendors are doing exactly that - phasing out old versions and requiring upgrading to new versions, all the time, both in open source and proprietary world. Yet I don't remember any of the vendors gaining reputation of particularly insecure product because of such upgrade strategy. I do not see why MW would be an exception.
I think most people that have business talking about security and evaluating which product is secure and which is not can distinguish the case of product being flawed from the case of somebody running an ancient version of the software and never upgrading. Maybe I'm too optimistic, but I also think solving an education problem by never educating and staying on ancient versions out of fear that uneducated FUD may hurt our reputation does not sound like a winning strategy for me.
On 20 Jul 2015, at 22:42, Legoktm legoktm.wikipedia@gmail.com wrote:
OTOH, if we never bump our version requirements, there's less incentive for hosting providers to upgrade their PHP. [1] has some interesting arguments regarding this.
[1] http://blog.ircmaxell.com/2014/12/on-php-version-requirements.html
Indeed. Providers that don't already provide newer PHP options, will certainly start doing so when major software requires it.
On 21 Jul 2015, at 07:12, bawolff bawolff+wn@gmail.com wrote:
https://wikiapiary.com/w/index.php?title=Special:SearchByProperty&limit=... is also something to keep in mind
Yes, but also keep in mind that many of those wikis likely run in hosting environments that already support newer PHP versions. But customers won't change their settings until they have to. And providers can't change customers proactively without risking site breakage or damaging customer relations.
I had the same with my third-party wikis. Until recently they ran on PHP 5.3. Then at some point I realised my provider had a simple "Select PHP Version" page in the control panel. I switched them all to PHP 5.6 that day and also enabled opcache. Site performance improved greatly.
On 19 Jul 2015, at 07:15, Bryan Davis bd808@wikimedia.org wrote:
Some WMF production hosts are still on PHP 5.3.10 so as Tim pointed out last spring [0] we shouldn't drop 5.3 support until after the entirety of the WMF server fleet are all switched over to HHVM or at least a newer version of PHP5. [..]
Yeah, in case of Wikimedia master is near-immediate production so let's post-pone this until right after Wikimedia's migration is complete.
Third parties can stick to using the LTS or the current stable version as needed for upto several years more without issue.
-- Krinkle
side note: How come php 5.3.3 support broken accidentally? Isn't Jenkins script validates compatibility with the min php? :)
On Wed, Jul 22, 2015 at 9:36 PM, Krinkle krinklemail@gmail.com wrote:
On 20 Jul 2015, at 22:42, Legoktm legoktm.wikipedia@gmail.com wrote:
OTOH, if we never bump our version requirements, there's less incentive for hosting providers to upgrade their PHP. [1] has some interesting arguments regarding this.
[1] http://blog.ircmaxell.com/2014/12/on-php-version-requirements.html
Indeed. Providers that don't already provide newer PHP options, will certainly start doing so when major software requires it.
On 21 Jul 2015, at 07:12, bawolff bawolff+wn@gmail.com wrote:
https://wikiapiary.com/w/index.php?title=Special:SearchByProperty&limit=...
is also something to keep in mind
Yes, but also keep in mind that many of those wikis likely run in hosting environments that already support newer PHP versions. But customers won't change their settings until they have to. And providers can't change customers proactively without risking site breakage or damaging customer relations.
I had the same with my third-party wikis. Until recently they ran on PHP 5.3. Then at some point I realised my provider had a simple "Select PHP Version" page in the control panel. I switched them all to PHP 5.6 that day and also enabled opcache. Site performance improved greatly.
On 19 Jul 2015, at 07:15, Bryan Davis bd808@wikimedia.org wrote:
Some WMF production hosts are still on PHP 5.3.10 so as Tim pointed out last spring [0] we shouldn't drop 5.3 support until after the entirety of the WMF server fleet are all switched over to HHVM or at least a newer version of PHP5. [..]
Yeah, in case of Wikimedia master is near-immediate production so let's post-pone this until right after Wikimedia's migration is complete.
Third parties can stick to using the LTS or the current stable version as needed for upto several years more without issue.
-- Krinkle
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Maybe another php bump to something like 5.3.6. I think one php 5.3 usage goes down then we should switch to something like php 5.5 or 5.6 or even php 7 if php 7 get enough popularity.
On Wednesday, 22 July 2015, 21:19, Eran Rosenthal eranroz89@gmail.com wrote:
side note: How come php 5.3.3 support broken accidentally? Isn't Jenkins script validates compatibility with the min php? :)
On Wed, Jul 22, 2015 at 9:36 PM, Krinkle krinklemail@gmail.com wrote:
On 20 Jul 2015, at 22:42, Legoktm legoktm.wikipedia@gmail.com wrote:
OTOH, if we never bump our version requirements, there's less incentive for hosting providers to upgrade their PHP. [1] has some interesting arguments regarding this.
[1] http://blog.ircmaxell.com/2014/12/on-php-version-requirements.html
Indeed. Providers that don't already provide newer PHP options, will certainly start doing so when major software requires it.
On 21 Jul 2015, at 07:12, bawolff bawolff+wn@gmail.com wrote:
https://wikiapiary.com/w/index.php?title=Special:SearchByProperty&limit=...
is also something to keep in mind
Yes, but also keep in mind that many of those wikis likely run in hosting environments that already support newer PHP versions. But customers won't change their settings until they have to. And providers can't change customers proactively without risking site breakage or damaging customer relations.
I had the same with my third-party wikis. Until recently they ran on PHP 5.3. Then at some point I realised my provider had a simple "Select PHP Version" page in the control panel. I switched them all to PHP 5.6 that day and also enabled opcache. Site performance improved greatly.
On 19 Jul 2015, at 07:15, Bryan Davis bd808@wikimedia.org wrote:
Some WMF production hosts are still on PHP 5.3.10 so as Tim pointed out last spring [0] we shouldn't drop 5.3 support until after the entirety of the WMF server fleet are all switched over to HHVM or at least a newer version of PHP5. [..]
Yeah, in case of Wikimedia master is near-immediate production so let's post-pone this until right after Wikimedia's migration is complete.
Third parties can stick to using the LTS or the current stable version as needed for upto several years more without issue.
-- Krinkle
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, 22 Jul 2015 22:18:57 +0200, Eran Rosenthal eranroz89@gmail.com wrote:
side note: How come php 5.3.3 support broken accidentally? Isn't Jenkins script validates compatibility with the min php? :)
We run unit tests, but on PHP 5.3.10, according to the console output. (For example https://integration.wikimedia.org/ci/job/mediawiki-phpunit-zend/6594/console...)
(Also, that only catches incompatibilities in code that has unit tests. ;) I've ran into 5.3 compat breakages in the past when I added new features with tests, that used some existing code without tests.)
(Also, that only catches incompatibilities in code that has unit tests. ;) I've ran into 5.3 compat breakages in the past when I added new features with tests, that used some existing code without tests.)
Just for reference, in this case, I'm pretty sure the code in question has unit tests
--bawolff
On Thu, 23 Jul 2015 12:19:13 +0200, bawolff bawolff+wn@gmail.com wrote:
Just for reference, in this case, I'm pretty sure the code in question has unit tests
Yes, it does.
(For posterity, my example was commit 5042d260ce5190cce0c325b7cb5b618b3cff73bc, which fixed 5.3 compat breakage caught by 5ed35b04c99abbd7a8d015402f359c7002c491eb, a regression from aa00a3e8384a87430f82739507e09bb74c6b40ec. All three commits in this case were my own.)
wikitech-l@lists.wikimedia.org