PHP 5.4 added a few important features[1], namely traits, shorthand array syntax, and function array dereferencing. I've heard that 5.3 is nearing end of life.
I propose we drop support for PHP 5.3 soon, if possible.
- Trevor
On Tue, Feb 18, 2014 at 9:48 AM, Trevor Parscal tparscal@wikimedia.orgwrote:
PHP 5.4 added a few important features[1], namely traits, shorthand array syntax, and function array dereferencing. I've heard that 5.3 is nearing end of life.
I propose we drop support for PHP 5.3 soon, if possible.
I'm in favor of bumping to a 5.4 minimum as well since 5.3 is approaching its end of life upstream.
As I pointed out on IRC, the question is how quickly the distros will follow. Right now the current Ubuntu LTS has us stuck on 5.3.something. It looks like 14.04 will have 5.5.8 which is nice but not out until April :)
-Chad
On Tue, Feb 18, 2014 at 09:51:25AM -0800, Chad wrote:
On Tue, Feb 18, 2014 at 9:48 AM, Trevor Parscal tparscal@wikimedia.orgwrote:
PHP 5.4 added a few important features[1], namely traits, shorthand array syntax, and function array dereferencing. I've heard that 5.3 is nearing end of life.
I propose we drop support for PHP 5.3 soon, if possible.
I'm in favor of bumping to a 5.4 minimum as well since 5.3 is approaching its end of life upstream.
As I pointed out on IRC, the question is how quickly the distros will follow. Right now the current Ubuntu LTS has us stuck on 5.3.something. It looks like 14.04 will have 5.5.8 which is nice but not out until April :)
That is not actually the holdup (or if it is, it's a miscommunication and it shouldn't be). We can backport/build/maintain PHP packages ourselves. We, in fact, run our own 5.3 packages with some minor changes compared to precise's.
Last time we were discussing PHP 5.4 it was quite a while ago but I remember hearing that we'd need to do some porting work for our extensions. Plus, we we re having a debate we were having about Suhosin that I don't think ended up anywhere :)
However, last I heard, platform engineering is focusing on HHVM now instead, so I'm not sure if it actually makes sense to spend resources to move to PHP 5.4 right now.
Faidon
On 02/18/2014 01:10 PM, Faidon Liambotis wrote:
However, last I heard, platform engineering is focusing on HHVM now instead, so I'm not sure if it actually makes sense to spend resources to move to PHP 5.4 right now.
My understanding is that those are two orthogonal questions. I don't think we plan on demanding that external users all use HHVM to run Mediawiki, so the question "which is the least version of PHP supported by core" remains valid.
-- Marc
On Feb 18, 2014, at 10:10 AM, Faidon Liambotis faidon@wikimedia.org wrote:
However, last I heard, platform engineering is focusing on HHVM now instead, so I'm not sure if it actually makes sense to spend resources to move to PHP 5.4 right now.
Just as a data point, Wikia already runs php 5.4 in production. If I remember correctly there were some things that had to be fixed around the (deprecated in 5.3) call time pass by reference “feature” being removed, but it wasn’t much effort at all.
Regarding PHP 5.3 support, I put together a quick report in WikiApiary showing the versions of PHP in use across wikis.
https://wikiapiary.com/wiki/PHP_Versions
In short, 5.3 is the most common PHP version used by a large, large majority.
Three things to footnote in this data (and you could run additional queries to get the real data for these).
1. WMF itself runs PHP 5.3, so that explodes the user count a lot. If you excluded WMF (based on an assumption that WMF controls it so thus could move to newer version easily) it lowers the active users on 5.3 dramatically.
2. A large percentage of the 5.3 install base is there because that is what Ubuntu is distributing (my farm is on 5.3 for this reason). If there was an easy PPA solution to move from 5.3 to 5.4 for Ubuntu 12.04 that would also lessen the dependency on 5.3.
3. If you queried by Netblock you could identify how many of these 5.3 users are on Bluehost, Dreamhost or other system where they have no ability to upgrade, the hosted would have to do that.
All data (except time series edit data) for WikiApiary is stored as semantic properties, so all of these things are available for #ask queries.
On 20/02/14 05:17, Jamie Thingelstad wrote:
Regarding PHP 5.3 support, I put together a quick report in WikiApiary showing the versions of PHP in use across wikis.
https://wikiapiary.com/wiki/PHP_Versions
In short, 5.3 is the most common PHP version used by a large, large majority.
Three things to footnote in this data (and you could run additional queries to get the real data for these).
- WMF itself runs PHP 5.3, so that explodes the user count a lot. If
you excluded WMF (based on an assumption that WMF controls it so thus could move to newer version easily) it lowers the active users on 5.3 dramatically.
- A large percentage of the 5.3 install base is there because that is
what Ubuntu is distributing (my farm is on 5.3 for this reason). If there was an easy PPA solution to move from 5.3 to 5.4 for Ubuntu 12.04 that would also lessen the dependency on 5.3.
FWIW, the next long-term support (LTS) version of Ubuntu is due on 17 April this year. It ships with PHP 5.5. This would be the Ubuntu version that hosters would want to upgrade to. However, the previous LTS version will still be supported until April 2017, so there is no urge for people to upgrade.
Cheers,
Markus
- If you queried by Netblock you could identify how many of these 5.3
users are on Bluehost, Dreamhost or other system where they have no ability to upgrade, the hosted would have to do that.
All data (except time series edit data) for WikiApiary is stored as semantic properties, so all of these things are available for #ask queries.
Is that the rule then, we have to make MediaWiki work on anything Ubuntu still supports?
Is there a rule?
- Trevor
On Thu, Feb 20, 2014 at 12:25 AM, Markus Krötzsch < markus@semantic-mediawiki.org> wrote:
On 20/02/14 05:17, Jamie Thingelstad wrote:
Regarding PHP 5.3 support, I put together a quick report in WikiApiary showing the versions of PHP in use across wikis.
https://wikiapiary.com/wiki/PHP_Versions
In short, 5.3 is the most common PHP version used by a large, large majority.
Three things to footnote in this data (and you could run additional queries to get the real data for these).
- WMF itself runs PHP 5.3, so that explodes the user count a lot. If
you excluded WMF (based on an assumption that WMF controls it so thus could move to newer version easily) it lowers the active users on 5.3 dramatically.
- A large percentage of the 5.3 install base is there because that is
what Ubuntu is distributing (my farm is on 5.3 for this reason). If there was an easy PPA solution to move from 5.3 to 5.4 for Ubuntu 12.04 that would also lessen the dependency on 5.3.
FWIW, the next long-term support (LTS) version of Ubuntu is due on 17 April this year. It ships with PHP 5.5. This would be the Ubuntu version that hosters would want to upgrade to. However, the previous LTS version will still be supported until April 2017, so there is no urge for people to upgrade.
Cheers,
Markus
- If you queried by Netblock you could identify how many of these 5.3
users are on Bluehost, Dreamhost or other system where they have no ability to upgrade, the hosted would have to do that.
All data (except time series edit data) for WikiApiary is stored as semantic properties, so all of these things are available for #ask queries.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Maybe not a firm rule, but something worth being aware of. Lots of people use LTSes, so it'd be nice to not break them without some upgrade path :)
-Chad
On Thu, Feb 20, 2014 at 3:22 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
Is that the rule then, we have to make MediaWiki work on anything Ubuntu still supports?
Is there a rule?
- Trevor
On Thu, Feb 20, 2014 at 12:25 AM, Markus Krötzsch < markus@semantic-mediawiki.org> wrote:
On 20/02/14 05:17, Jamie Thingelstad wrote:
Regarding PHP 5.3 support, I put together a quick report in WikiApiary showing the versions of PHP in use across wikis.
https://wikiapiary.com/wiki/PHP_Versions
In short, 5.3 is the most common PHP version used by a large, large majority.
Three things to footnote in this data (and you could run additional queries to get the real data for these).
- WMF itself runs PHP 5.3, so that explodes the user count a lot. If
you excluded WMF (based on an assumption that WMF controls it so thus could move to newer version easily) it lowers the active users on 5.3 dramatically.
- A large percentage of the 5.3 install base is there because that is
what Ubuntu is distributing (my farm is on 5.3 for this reason). If there was an easy PPA solution to move from 5.3 to 5.4 for Ubuntu 12.04 that would also lessen the dependency on 5.3.
FWIW, the next long-term support (LTS) version of Ubuntu is due on 17 April this year. It ships with PHP 5.5. This would be the Ubuntu version that hosters would want to upgrade to. However, the previous LTS version will still be supported until April 2017, so there is no urge for people
to
upgrade.
Cheers,
Markus
- If you queried by Netblock you could identify how many of these 5.3
users are on Bluehost, Dreamhost or other system where they have no ability to upgrade, the hosted would have to do that.
All data (except time series edit data) for WikiApiary is stored as semantic properties, so all of these things are available for #ask queries.
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 Thu, Feb 20, 2014 at 3:22 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
Is that the rule then, we have to make MediaWiki work on anything Ubuntu still supports?
Is there a rule?
We should strongly consider ensuring that the latest stable releases of Ubuntu and probably RHEL (or maybe fedora) can run MediaWiki.
- Ryan
On 20 February 2014 15:34, Ryan Lane rlane32@gmail.com wrote:
On Thu, Feb 20, 2014 at 3:22 PM, Trevor Parscal <tparscal@wikimedia.org
wrote:
Is that the rule then, we have to make MediaWiki work on anything Ubuntu still supports?
Is there a rule?
We should strongly consider ensuring that the latest stable releases of Ubuntu and probably RHEL (or maybe fedora) can run MediaWiki.
Is that a "no, only the latest stable releases", or "yes, the latest stable releases and also the LTS releases"?
J.
On Thu, Feb 20, 2014 at 3:58 PM, James Forrester jforrester@wikimedia.orgwrote:
On 20 February 2014 15:34, Ryan Lane rlane32@gmail.com wrote:
On Thu, Feb 20, 2014 at 3:22 PM, Trevor Parscal <tparscal@wikimedia.org
wrote:
Is that the rule then, we have to make MediaWiki work on anything
Ubuntu
still supports?
Is there a rule?
We should strongly consider ensuring that the latest stable releases of Ubuntu and probably RHEL (or maybe fedora) can run MediaWiki.
Is that a "no, only the latest stable releases", or "yes, the latest stable releases and also the LTS releases"?
If it isn't an LTS it isn't a stable release.
- Ryan
Let me put this out there so there isn’t confusion. The regular 6 month releases of Ubuntu are the stable releases. A LTS release is released every two years on the same cycle as regular Ubuntu releases. A LTS release is certainly more stable than regular releases, but not calling regular releases stable is a bit misleading.
Techman224
On Feb 20, 2014, at 6:02 PM, Ryan Lane rlane32@gmail.com wrote:
On Thu, Feb 20, 2014 at 3:58 PM, James Forrester jforrester@wikimedia.orgwrote:
On 20 February 2014 15:34, Ryan Lane rlane32@gmail.com wrote:
On Thu, Feb 20, 2014 at 3:22 PM, Trevor Parscal <tparscal@wikimedia.org
wrote:
Is that the rule then, we have to make MediaWiki work on anything
Ubuntu
still supports?
Is there a rule?
We should strongly consider ensuring that the latest stable releases of Ubuntu and probably RHEL (or maybe fedora) can run MediaWiki.
Is that a "no, only the latest stable releases", or "yes, the latest stable releases and also the LTS releases"?
If it isn't an LTS it isn't a stable release.
- Ryan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 21 February 2014 01:00, Techman224 techman224@techman224.ca wrote:
Let me put this out there so there isn’t confusion. The regular 6 month releases of Ubuntu are the stable releases. A LTS release is released every two years on the same cycle as regular Ubuntu releases. A LTS release is certainly more stable than regular releases, but not calling regular releases stable is a bit misleading.
For server purposes, I think we can stick to LTSes. Approximately nobody runs a non-LTS Ubuntu for their web hosting. (And even less now that non-LTSes are only getting a nine-month lifetime.)
- d.
Being a firm believer in the LTS model, I support David's take on this issue. Besides, they tend to be tested and reliable and have a longer support window by default, so it makes sense to support them in turn.
From: dgerard@gmail.com Date: Fri, 21 Feb 2014 01:04:39 +0000 To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Drop support for PHP 5.3
On 21 February 2014 01:00, Techman224 techman224@techman224.ca wrote:
Let me put this out there so there isn’t confusion. The regular 6 month releases of Ubuntu are the stable releases. A LTS release is released every two years on the same cycle as regular Ubuntu releases. A LTS release is certainly more stable than regular releases, but not calling regular releases stable is a bit misleading.
For server purposes, I think we can stick to LTSes. Approximately nobody runs a non-LTS Ubuntu for their web hosting. (And even less now that non-LTSes are only getting a nine-month lifetime.)
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
and on my one webserver which *doesn't* run the LTS (for advance testing purposes, mostly) I just got caught by an increase from Apache2.2 to 2.4 which breaks all the things*.
AlisonW
* well, quite a lot, anyway. Much editing of configuration files and temporarily making some facilities entirely unavailable while searching documentation to find out WTF is the way to do what I need now.
----- Original Message -----
On 21 February 2014 01:00, Techman224 techman224@techman224.ca wrote:
Let me put this out there so there isn’t confusion. The regular 6 month releases of Ubuntu are the stable releases. A LTS release is released every two years on the same cycle as regular Ubuntu releases. A LTS release is certainly more stable than regular releases, but not calling regular releases stable is a bit misleading.
For server purposes, I think we can stick to LTSes. Approximately nobody runs a non-LTS Ubuntu for their web hosting. (And even less now that non-LTSes are only getting a nine-month lifetime.)
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
So, it sounds like we will either maybe drop 5.3 after April, or my newborn son will be riding a bicycle before we can use Traits in PHP.
Hoping for the former, willing to accept the latter.
- Trevor
On Fri, Feb 21, 2014 at 9:19 AM, AlisonW tech@alisonwheeler.com wrote:
and on my one webserver which *doesn't* run the LTS (for advance testing purposes, mostly) I just got caught by an increase from Apache2.2 to 2.4 which breaks all the things*.
AlisonW
- well, quite a lot, anyway. Much editing of configuration files and
temporarily making some facilities entirely unavailable while searching documentation to find out WTF is the way to do what I need now.
----- Original Message -----
On 21 February 2014 01:00, Techman224 techman224@techman224.ca wrote:
Let me put this out there so there isn't confusion. The regular 6 month releases of Ubuntu are the stable releases. A LTS release is released every two years on the same cycle as regular Ubuntu releases. A LTS release is certainly more stable than regular releases, but not calling regular releases stable is a bit misleading.
For server purposes, I think we can stick to LTSes. Approximately nobody runs a non-LTS Ubuntu for their web hosting. (And even less now that non-LTSes are only getting a nine-month lifetime.)
- d.
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
I'd say we could have a serious discussion about it come April or May; maybe with some new numbers if Jamie would be so kind :)
-Chad
On Fri, Feb 21, 2014 at 4:29 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
So, it sounds like we will either maybe drop 5.3 after April, or my newborn son will be riding a bicycle before we can use Traits in PHP.
Hoping for the former, willing to accept the latter.
- Trevor
On Fri, Feb 21, 2014 at 9:19 AM, AlisonW tech@alisonwheeler.com wrote:
and on my one webserver which *doesn't* run the LTS (for advance testing purposes, mostly) I just got caught by an increase from Apache2.2 to 2.4 which breaks all the things*.
AlisonW
- well, quite a lot, anyway. Much editing of configuration files and
temporarily making some facilities entirely unavailable while searching documentation to find out WTF is the way to do what I need now.
----- Original Message -----
On 21 February 2014 01:00, Techman224 techman224@techman224.ca
wrote:
Let me put this out there so there isn't confusion. The regular 6
month
releases of Ubuntu are the stable releases. A LTS release is released every two years on the same cycle as regular Ubuntu releases. A LTS release is certainly more stable than regular releases, but not
calling
regular releases stable is a bit misleading.
For server purposes, I think we can stick to LTSes. Approximately nobody runs a non-LTS Ubuntu for their web hosting. (And even less now that non-LTSes are only getting a nine-month lifetime.)
- d.
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
The data on that page is dynamic and is never more than 24 hours old.
(WikiApiary collects general data like that every 24 hours from all wikis it monitors.)
We should strongly consider ensuring that the latest stable releases of Ubuntu and probably RHEL (or maybe fedora) can run MediaWiki.
- Ryan
Kind of agree ;)
I'd like to see the next MediaWiki LTS version (1.23) to support PHP 5.3. MW1.23LTS has a scheduled release date at end of April (we might add a week or two for safety). After that, no problem from my side (release management) with dropping PHP5.3 support.
It might have been said before (tl;dr the whole thread) : a vast majority of 3rd party MW users still relies on PHP5.3. This is not a reason to block future improvements, but a fact to consider well. If we can agree on 1.23LTS supporting PHP5.3, imho, that'll do the trick.
Best, Markus (mglaser)
On 23 February 2014 01:25, Markus Glaser glaser@hallowelt.biz wrote:
I'd like to see the next MediaWiki LTS version (1.23) to support PHP 5.3. MW1.23LTS has a scheduled release date at end of April (we might add a week or two for safety). After that, no problem from my side (release management) with dropping PHP5.3 support.
As an LTS user (typically on Ubuntu 12.04; assume hosting environments won't go 14.04 straight away), that would make me very happy :-) And would probably do, yes.
- d.
+1 here as well. Let's look at this for 1.24 :)
-Chad On Feb 23, 2014 8:42 AM, "David Gerard" dgerard@gmail.com wrote:
On 23 February 2014 01:25, Markus Glaser glaser@hallowelt.biz wrote:
I'd like to see the next MediaWiki LTS version (1.23) to support PHP 5.3. MW1.23LTS has a scheduled release date at end of April (we might add a
week or
two for safety). After that, no problem from my side (release
management) with
dropping PHP5.3 support.
As an LTS user (typically on Ubuntu 12.04; assume hosting environments won't go 14.04 straight away), that would make me very happy :-) And would probably do, yes.
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I know a few people who will be happy if they can keep running on stock rhel6 (5.3). That would also mean epel can package 1.23.
After 1.19 is when we went to 5.3, so I think following president is good too. On Feb 23, 2014 6:04 PM, "Chad" innocentkiller@gmail.com wrote:
+1 here as well. Let's look at this for 1.24 :)
-Chad On Feb 23, 2014 8:42 AM, "David Gerard" dgerard@gmail.com wrote:
On 23 February 2014 01:25, Markus Glaser glaser@hallowelt.biz wrote:
I'd like to see the next MediaWiki LTS version (1.23) to support PHP
5.3.
MW1.23LTS has a scheduled release date at end of April (we might add a
week or
two for safety). After that, no problem from my side (release
management) with
dropping PHP5.3 support.
As an LTS user (typically on Ubuntu 12.04; assume hosting environments won't go 14.04 straight away), that would make me very happy :-) And would probably do, yes.
- d.
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
Hey,
I would like to present Jamie with the official barn-kitten of useful data brought to a wikitech thread. https://pbs.twimg.com/media/Bg9lHl8CMAAhXz-.jpg
Congratulations Jamie!
I'd also like to take this opportunity to start an RFC on redesigning all of MediaWiki's UI, with me doing the work. Clearly my Gimp skills can bring us to the next level.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --
On Tue, Feb 18, 2014 at 10:10 AM, Faidon Liambotis faidon@wikimedia.orgwrote:
Last time we were discussing PHP 5.4 it was quite a while ago but I remember hearing that we'd need to do some porting work for our extensions. Plus, we we re having a debate we were having about Suhosin that I don't think ended up anywhere :)
On that front, I think everyone who was holding out for Suhosin had conceded that it wasn't going to happen, so that's not a blocker.
However, last I heard, platform engineering is focusing on HHVM now instead, so I'm not sure if it actually makes sense to spend resources to move to PHP 5.4 right now.
Agreed. We've started work in earnest, with the goal of getting one service deployed in HipHop soon: https://www.mediawiki.org/wiki/HipHop_deployment
After we get that service deployed, we may need to set aside that work for other priorities. We'll be assessing at our next quarterly review in April, deciding if we want to finish off the job quickly, or if we need to let it rest while more bugs are knocked out of the system. If it looks like it's going to take a while, we can also decide if we want a PHP 5.4 upgrade prior to a full cutover to HipHop.
Rob
On Feb 18, 2014 8:11 AM, "Faidon Liambotis" faidon@wikimedia.org wrote:
Last time we were discussing PHP 5.4 it was quite a while ago but I remember hearing that we'd need to do some porting work for our extensions.
Is this still the case? If so, it seems the first step would be for WMF to ensure that it can run on 5.4 (and transition prod to 5.4?), before dropping support for 5.3. --scott
I support this. Adequate testing of 5.4 before abandonment of 5.3 would be a sensible prelude to any major decision concerning this matter.
Date: Fri, 21 Feb 2014 16:37:24 -1000 From: cananian@wikimedia.org To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Drop support for PHP 5.3
On Feb 18, 2014 8:11 AM, "Faidon Liambotis" faidon@wikimedia.org wrote:
Last time we were discussing PHP 5.4 it was quite a while ago but I remember hearing that we'd need to do some porting work for our extensions.
Is this still the case? If so, it seems the first step would be for WMF to ensure that it can run on 5.4 (and transition prod to 5.4?), before dropping support for 5.3. --scott _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Feb 21, 2014 at 6:37 PM, C. Scott Ananian cananian@wikimedia.orgwrote:
On Feb 18, 2014 8:11 AM, "Faidon Liambotis" faidon@wikimedia.org wrote:
Last time we were discussing PHP 5.4 it was quite a while ago but I remember hearing that we'd need to do some porting work for our extensions.
Is this still the case? If so, it seems the first step would be for WMF to ensure that it can run on 5.4 (and transition prod to 5.4?), before dropping support for 5.3.
If we go with HHVM we'll basically be jumping to 5.5.x ;-)
-Chad
On Tue, Feb 18, 2014 at 12:48 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
I propose we drop support for PHP 5.3 soon, if possible.
Agreed, but right now both Debian oldstable and Ubuntu LTS are running on PHP 5.3. I'm pretty sure (last time I checked) that both reach their EOL sometime this summer, like in July or something. Once that happens we can safely stop supporting 5.3 with the next MediaWiki release.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
On Tue, Feb 18, 2014 at 10:54 AM, Tyler Romeo tylerromeo@gmail.com wrote:
On Tue, Feb 18, 2014 at 12:48 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
I propose we drop support for PHP 5.3 soon, if possible.
Agreed, but right now both Debian oldstable and Ubuntu LTS are running on PHP 5.3. I'm pretty sure (last time I checked) that both reach their EOL sometime this summer, like in July or something. Once that happens we can safely stop supporting 5.3 with the next MediaWiki release.
Ubuntu Server LTS versions have 5 years of support, so 12.04 will not be EOL until April of 2017. PHP 5.3 will be EOL in July of 2014. I'm sure that 3 year difference will be a major pain point for the Ubuntu security team.
Bryan
On Tue, Feb 18, 2014 at 1:14 PM, Bryan Davis bd808@wikimedia.org wrote:
Ubuntu Server LTS versions have 5 years of support, so 12.04 will not be EOL until April of 2017. PHP 5.3 will be EOL in July of 2014. I'm sure that 3 year difference will be a major pain point for the Ubuntu security team.
OK, so Ubuntu Server LTS will EOL in April 2017. Additionally, MediaWiki 1.23 LTS (our next release) is planned to EOL in May 2017. With that in mind, I think it's fair to say that once 1.23 is released we will have the opportunity to increase our PHP requirement.
I strongly recommend we do so. A list of nice things about 5.4 that we'd definitely use:
- Array literals - $this support in closures - Class member access based on expression - Class member access after instantiation - Function return value array dereferencing - The JsonSerializable interface - Improved parse_url() behavior
Of course there is traits as well, but that's more of an actual new feature, and it will be a while before MediaWiki starts using traits everywhere.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
On Tue, Feb 18, 2014 at 5:41 PM, Tyler Romeo tylerromeo@gmail.com wrote:
On Tue, Feb 18, 2014 at 1:14 PM, Bryan Davis bd808@wikimedia.org wrote:
Ubuntu Server LTS versions have 5 years of support, so 12.04 will not be EOL until April of 2017. PHP 5.3 will be EOL in July of 2014. I'm sure that 3 year difference will be a major pain point for the Ubuntu security team.
OK, so Ubuntu Server LTS will EOL in April 2017. Additionally, MediaWiki 1.23 LTS (our next release) is planned to EOL in May 2017. With that in mind, I think it's fair to say that once 1.23 is released we will have the opportunity to increase our PHP requirement.
I strongly recommend we do so. A list of nice things about 5.4 that we'd definitely use:
- Array literals
- $this support in closures
- Class member access based on expression
- Class member access after instantiation
- Function return value array dereferencing
- The JsonSerializable interface
- Improved parse_url() behavior
Of course there is traits as well, but that's more of an actual new feature, and it will be a while before MediaWiki starts using traits everywhere.
+1 on making the break in 1.24. I actually have a note on my desktop reminding me to write an RFC on that very topic. We should wait to see but I'm guessing we can skip right over 5.4 and move up to 5.5 when we drop 5.3 support.
Bryan
On 2014-02-18 4:41 PM, Tyler Romeo wrote:
I strongly recommend we do so. A list of nice things about 5.4 that we'd definitely use:
- Array literals
- $this support in closures
- Class member access based on expression
- Class member access after instantiation
- Function return value array dereferencing
- The JsonSerializable interface
- Improved parse_url() behavior
Of course there is traits as well, but that's more of an actual new feature, and it will be a while before MediaWiki starts using traits everywhere.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
Actually we'll have even more uses for PHP 5.4: - <?= ?> in skins instead of <?php echo ?> where we do do that. - No more need for safe_mode checks - We can kill our register_global checks in WebStart.php - No more magic_quotes_gpc handling in WebRequestk
But also we do already have a use for traits, RequestContext. We extend from ContextSource because we can't currently use a TContextSource trait. This is fine for the classes that have no parent class but we've run into classes that already have prior obligations. In those instances some code duplication has been necessary.
^_^ With traits we can redefine the ContextSource class as the following and make anything duplicating ContextSource code use a trait.
class ContextSource implements IContextSource { use TContextSource; }
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
2014-02-18 19:14 GMT+01:00 Bryan Davis bd808@wikimedia.org:
On Tue, Feb 18, 2014 at 10:54 AM, Tyler Romeo tylerromeo@gmail.com wrote:
On Tue, Feb 18, 2014 at 12:48 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
I propose we drop support for PHP 5.3 soon, if possible.
Agreed, but right now both Debian oldstable and Ubuntu LTS are running on PHP 5.3. I'm pretty sure (last time I checked) that both reach their EOL sometime this summer, like in July or something. Once that happens we can safely stop supporting 5.3 with the next MediaWiki release.
Ubuntu Server LTS versions have 5 years of support, so 12.04 will not be EOL until April of 2017. PHP 5.3 will be EOL in July of 2014. I'm sure that 3 year difference will be a major pain point for the Ubuntu security team.
Also Ubuntu Server LTS 10.04 (aka Lucid Lynx) will EOF in April 2015. They have PHP 5.3.2 now (see also: https://en.wikipedia.org/wiki/List_of_Ubuntu_releases#Version_timeline)
Cristian (who had recently an issue with this since the latest CiviCRM versions require PHP >= 5.3.3) -__-''
Le 18/02/2014 18:48, Trevor Parscal a écrit :
PHP 5.4 added a few important features[1], namely traits, shorthand array syntax, and function array dereferencing. I've heard that 5.3 is nearing end of life.
I propose we drop support for PHP 5.3 soon, if possible.
Hello,
One of the requirement we have enforced is that MediaWiki must be installable on Debian stable. The current stable version ships 5.4 now so that is a fulfilled requirement.
Ubuntu Precise LTS has php 5.3. We have a MediaWiki LTS as well, so people can use that instead of the latest version.
We want MediaWiki to be installable on as many hosting services as possible. I do not have any metric, but hopefully most services come with php 5.4 nowadays. As for Ubuntu, if someone hosting service still use php 5.3, they can use the MediaWiki LTS version.
A requirement Wikimedia has nowadays is that the code MUST be supported with HipHop Virtual Machine. As an example, I do not think it implements the SPL classes. So that needs to be carefully checked.
Another very important point is whether we want to actually use 5.4 new features. Reviewing the list of 5.3 new features:
* namespaces : we did not see a good use case for them
* Late Static Bindings : consensus that it is merely a workaround for badly designed code
* jump labels : dinosaur will eat you http://www.xkcd.com/292/ ( I like goto myself and yeah they have valid use cases ).
* Closures (lambda/anonymous) : that made the code easier to follow when using callbacks since the callbacks code is next to the caller.
* __callStatic() __invoke() : never seen that used in our code
* Constants declared with 'const' : we use define()
* short ternary operator '?:' : haven't seen it
* nested exceptions : maybe we end up using them somehow. Not sure.
* circular refs garbage collection : it is enabled by default
Of course you have some new functions and build-in classes. But beside that, we barely use any 5.3 new features.
I do not think this thread is a good opportunity to bikeshed/talk/reach consensus about 5.4 features. That is eventually a can of worm that would need to be opened and some consensus reached for each features.
The real blocker is hhvm matching 5.4 features.
List of new features:
http://php.net/manual/en/migration53.new-features.php http://php.net/manual/en/migration54.new-features.php
On Wed, Feb 19, 2014 at 5:49 AM, Antoine Musso hashar+wmf@free.fr wrote:
- short ternary operator '?:' : haven't seen it
It's being used in a few places; probably a variation that was equivalent to isset( $foo ) ? $foo : $bar would see more use though.
On 20/02/14 01:46, Brad Jorsch (Anomie) wrote:
On Wed, Feb 19, 2014 at 5:49 AM, Antoine Musso hashar+wmf@free.fr wrote:
- short ternary operator '?:' : haven't seen it
It's being used in a few places; probably a variation that was equivalent to isset( $foo ) ? $foo : $bar would see more use though.
On one code review when Aaron used ?:, he said that he was surprised that I didn't object to it. I said that it's basically the same as the "or" operator in Lua or JavaScript, and I think it's used quite elegantly in those languages.
I think it's ridiculous to refer to it as a ternary operator when it takes two operands, and by extension, in the PHP grammar, it should have been a single token binary operator ?: with space disallowed in between ? and :, but other than that, I am fine with it.
-- Tim Starling
On 02/19/2014 05:49 AM, Antoine Musso wrote:
A requirement Wikimedia has nowadays is that the code MUST be supported with HipHop Virtual Machine. As an example, I do not think it implements the SPL classes. So that needs to be carefully checked.
A good number of them are available now (https://github.com/facebook/hhvm/tree/master/hphp/system/php/spl). I don't know if they all are.
Tyler Romeo worked on some of this (https://github.com/facebook/hhvm/pull/807).
Another very important point is whether we want to actually use 5.4 new features. Reviewing the list of 5.3 new features:
- namespaces : we did not see a good use case for them
It's useful for extensions. That way, an extension doesn't have to worry about the names of core classes, or future extensions, and it doesn't have to have prefixes in the class name itself.
- Constants declared with 'const' : we use define()
I've been using const. It's nicer syntax.
Matt Flaschen
On Tue, Feb 25, 2014 at 5:02 PM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
On 02/19/2014 05:49 AM, Antoine Musso wrote:
- namespaces : we did not see a good use case for them
It's useful for extensions. That way, an extension doesn't have to worry about the names of core classes, or future extensions, and it doesn't have to have prefixes in the class name itself.
Is there a difference between Extension\ClassName and Extension_ClassName, collision-wise? i.e. if two extensions both use "Extension" as a namespace and define "ClassName", what happens?
Namespaces do have opportunity to allow for shortened references within the extension. Although potentially with confusion, particularly if the shortened reference is hiding a "global" class of the same name (e.g. aliasing Extension\User to User).
The status quo has the advantage of not looking weird with backslashes ;)
On 02/25/2014 10:05 PM, Brad Jorsch (Anomie) wrote:
Namespaces do have opportunity to allow for shortened references within the extension. Although potentially with confusion, particularly if the shortened reference is hiding a "global" class of the same name (e.g. aliasing Extension\User to User).
Yes, that's the advantage. I wouldn't be so contrary as to make MyExtension\User, though. But I do have a PageFilter class safely namespaced like this, which could easily end up used as a name by core (but currently isn't) or an extension.
Matthew Flaschen
Le 26/02/2014 04:05, Brad Jorsch (Anomie) a écrit :
Is there a difference between Extension\ClassName and Extension_ClassName, collision-wise? i.e. if two extensions both use "Extension" as a namespace and define "ClassName", what happens?
I guess when in the namespace 'Extension' you can refer to 'ClassName' directly which saves a few keystrokes.
Le 25/02/2014 23:02, Matthew Flaschen a écrit :
A good number of SPL classes are available now (https://github.com/facebook/hhvm/tree/master/hphp/system/php/spl). I don't know if they all are.
Tyler Romeo worked on some of this (https://github.com/facebook/hhvm/pull/807).
Wonderful! I love how it is implementable using plain PHP.
Another very important point is whether we want to actually use 5.4 new features. Reviewing the list of 5.3 new features:
- namespaces : we did not see a good use case for them
It's useful for extensions. That way, an extension doesn't have to worry about the names of core classes, or future extensions, and it doesn't have to have prefixes in the class name itself.
I fully agree, it is definitely useful for extensions. For core there is less use though, we can always use Name_Spacing_Class class names.
- Constants declared with 'const' : we use define()
I've been using const. It's nicer syntax.
It seems the two differences is that const can only be used at compile time and that define() let you create case insensitive constants. I guess we could migrate to const though there is no added value beside being 'const' being nicer.
On Mon, Mar 3, 2014 at 8:57 AM, Antoine Musso hashar+wmf@free.fr wrote:
- Constants declared with 'const' : we use define()
I've been using const. It's nicer syntax.
It seems the two differences is that const can only be used at compile time and that define() let you create case insensitive constants. I guess we could migrate to const though there is no added value beside being 'const' being nicer.
Another difference here is that HHVM performs additional optimizations, like replacing constants with their value at compile time rather than looking up at runtime, when run with production settings (RepoAuthoritative mode). IIUC hhvm only performs these optimizations on const's and not dynamically define()'d values. Its likely a small difference, but useful.
Erik B.
--
Antoine "hashar" Musso
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 19/02/14 04:48, Trevor Parscal wrote:
PHP 5.4 added a few important features[1], namely traits, shorthand array syntax, and function array dereferencing.
For the record, I am fine with those three features being used in MediaWiki code, once we drop support for 5.3.
I've heard that 5.3 is nearing end of life.
I propose we drop support for PHP 5.3 soon, if possible.
Let's drop support for 5.3 after we switch the WMF servers to 5.4 or later. I think it would be inconvenient to be unable to run our software on our own servers. If you remember, that was also the trigger used for the dropping of PHP 4.x support, and also MySQL 4.0.x.
I think it is likely that this will be after April. So MW 1.23 will require PHP 5.3. After the WMF servers are switched over and 1.23 is out, we can consider general popularity. But I don't think we have to wait for Ubuntu 12.04 to go out of its support period or for usage of it to decline to 1% or anything like that. I think we are talking about mid-to-late 2014, depending on what happens with HHVM and the Ubuntu 14.04 migration project.
-- Tim Starling
wikitech-l@lists.wikimedia.org