Drop support for PHP 5.3

List overview All Threads
Download

newer

older

GSOC-2014 aspirant

Fw: Captcha Idea Proposal for GSOC...

Trevor Parscal

18 Feb 2014 18 Feb '14

6:48 p.m.

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 [1] http://php.net/manual/en/migration54.new-features.php

Show replies by date

Chad

18 Feb 18 Feb

6:51 p.m.

On Tue, Feb 18, 2014 at 9:48 AM, Trevor Parscal <tparscal(a)wikimedia.org>wrote;wrote:

...

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

Faidon Liambotis

7:10 p.m.

On Tue, Feb 18, 2014 at 09:51:25AM -0800, Chad wrote:

...

On Tue, Feb 18, 2014 at 9:48 AM, Trevor Parscal <tparscal(a)wikimedia.org>wrote;wrote:

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

Marc A. Pelletier

7:13 p.m.

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

Owen Davis

19 Feb 19 Feb

8:01 p.m.

On Feb 18, 2014, at 10:10 AM, Faidon Liambotis <faidon(a)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.

Jamie Thingelstad

20 Feb 20 Feb

5:17 a.m.

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. -- Jamie Thingelstad jamie(a)thingelstad.com On Wed, Feb 19, 2014, at 11:01 AM, Owen Davis wrote:

...

On Feb 18, 2014, at 10:10 AM, Faidon Liambotis <faidon(a)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. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Markus Krötzsch

9:25 a.m.

On 20/02/14 05:17, Jamie Thingelstad wrote:

...

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

...

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.

Trevor Parscal

21 Feb 21 Feb

12:22 a.m.

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(a)semantic-mediawiki.org> wrote:

...

On 20/02/14 05:17, Jamie Thingelstad wrote:

_______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Chad

12:31 a.m.

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(a)wikimedia.org>wrote;wrote:

...

On 20/02/14 05:17, Jamie Thingelstad wrote:

upgrade. Cheers, Markus

_______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Ryan Lane

12:34 a.m.

On Thu, Feb 20, 2014 at 3:22 PM, Trevor Parscal <tparscal(a)wikimedia.org>wrote;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. - Ryan

James Forrester

12:58 a.m.

On 20 February 2014 15:34, Ryan Lane <rlane32(a)gmail.com> wrote:

...

On Thu, Feb 20, 2014 at 3:22 PM, Trevor Parscal <tparscal(a)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. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

Ryan Lane

1:02 a.m.

On Thu, Feb 20, 2014 at 3:58 PM, James Forrester <jforrester(a)wikimedia.org>wrote;wrote:

...

On 20 February 2014 15:34, Ryan Lane <rlane32(a)gmail.com> wrote:

On Thu, Feb 20, 2014 at 3:22 PM, Trevor Parscal <tparscal(a)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

Techman224

2 a.m.

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(a)gmail.com> wrote:

...

On Thu, Feb 20, 2014 at 3:58 PM, James Forrester <jforrester(a)wikimedia.org>wrote;wrote:

On 20 February 2014 15:34, Ryan Lane <rlane32(a)gmail.com> wrote:

On Thu, Feb 20, 2014 at 3:22 PM, Trevor Parscal <tparscal(a)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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

David Gerard

2:04 a.m.

On 21 February 2014 01:00, Techman224 <techman224(a)techman224.ca> wrote:

...

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.

Arcane 21

2:57 a.m.

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(a)gmail.com Date: Fri, 21 Feb 2014 01:04:39 +0000 To: wikitech-l(a)lists.wikimedia.org Subject: Re: [Wikitech-l] Drop support for PHP 5.3 On 21 February 2014 01:00, Techman224 <techman224(a)techman224.ca> wrote:

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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

AlisonW

6:19 p.m.

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(a)techman224.ca> wrote:

Trevor Parscal

22 Feb 22 Feb

1:29 a.m.

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(a)alisonwheeler.com> wrote:

...

On 21 February 2014 01:00, Techman224 <techman224(a)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.

_______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Chad

3:21 a.m.

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(a)wikimedia.org>wrote;wrote:

...

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.

_______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Jamie Thingelstad

3:28 a.m.

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.) -- Jamie Thingelstad jamie(a)thingelstad.com On Fri, Feb 21, 2014, at 06:21 PM, Chad wrote:

...

wrote:

> > > Let me put this out there so there isn't confusion. The regular 6

month

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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Markus Glaser

23 Feb 23 Feb

2:25 a.m.

...

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)

David Gerard

5:41 p.m.

On 23 February 2014 01:25, Markus Glaser <glaser(a)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.

Chad

24 Feb 24 Feb

3:03 a.m.

+1 here as well. Let's look at this for 1.24 :) -Chad On Feb 23, 2014 8:42 AM, "David Gerard" <dgerard(a)gmail.com> wrote:

...

On 23 February 2014 01:25, Markus Glaser <glaser(a)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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Chris Steipp

4:17 p.m.

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(a)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(a)gmail.com> wrote:

On 23 February 2014 01:25, Markus Glaser <glaser(a)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.

_______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Jeroen De Dauw

21 Feb 21 Feb

2:56 a.m.

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 --

Rob Lanphier

3:31 a.m.

On Tue, Feb 18, 2014 at 10:10 AM, Faidon Liambotis <faidon(a)wikimedia.org>wrote;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. 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

C. Scott Ananian

22 Feb 22 Feb

3:37 a.m.

On Feb 18, 2014 8:11 AM, "Faidon Liambotis" <faidon(a)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

Arcane 21

3:42 a.m.

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(a)wikimedia.org To: wikitech-l(a)lists.wikimedia.org Subject: Re: [Wikitech-l] Drop support for PHP 5.3 On Feb 18, 2014 8:11 AM, "Faidon Liambotis" <faidon(a)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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Chad

3:56 a.m.

On Fri, Feb 21, 2014 at 6:37 PM, C. Scott Ananian <cananian(a)wikimedia.org>wrote;wrote:

...

On Feb 18, 2014 8:11 AM, "Faidon Liambotis" <faidon(a)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

Tyler Romeo

18 Feb 18 Feb

6:54 p.m.

On Tue, Feb 18, 2014 at 12:48 PM, Trevor Parscal <tparscal(a)wikimedia.org>wrote;wrote:

...

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

Bryan Davis

7:14 p.m.

On Tue, Feb 18, 2014 at 10:54 AM, Tyler Romeo <tylerromeo(a)gmail.com> wrote:

...

On Tue, Feb 18, 2014 at 12:48 PM, Trevor Parscal <tparscal(a)wikimedia.org>wrote;wrote:

I propose we drop support for PHP 5.3 soon, if possible.

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 -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855

Tyler Romeo

19 Feb 19 Feb

1:41 a.m.

On Tue, Feb 18, 2014 at 1:14 PM, Bryan Davis <bd808(a)wikimedia.org> wrote:

...

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

Bryan Davis

2:18 a.m.

On Tue, Feb 18, 2014 at 5:41 PM, Tyler Romeo <tylerromeo(a)gmail.com> wrote:

...

On Tue, Feb 18, 2014 at 1:14 PM, Bryan Davis <bd808(a)wikimedia.org> wrote:

+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 -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855

Daniel Friesen

2:26 a.m.

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/]

Cristian Consonni

3 Mar 3 Mar

6:54 p.m.

2014-02-18 19:14 GMT+01:00 Bryan Davis <bd808(a)wikimedia.org>rg>:

...

On Tue, Feb 18, 2014 at 10:54 AM, Tyler Romeo <tylerromeo(a)gmail.com> wrote:

On Tue, Feb 18, 2014 at 12:48 PM, Trevor Parscal <tparscal(a)wikimedia.org>wrote;wrote:

I propose we drop support for PHP 5.3 soon, if possible.

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) -__-''

Antoine Musso

19 Feb 19 Feb

11:49 a.m.

Le 18/02/2014 18:48, Trevor Parscal a écrit :

...

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 -- Antoine "hashar" Musso

Brad Jorsch (Anomie)

3:46 p.m.

On Wed, Feb 19, 2014 at 5:49 AM, Antoine Musso <hashar+wmf(a)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. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation

Tim Starling

26 Feb 26 Feb

3:51 a.m.

On 20/02/14 01:46, Brad Jorsch (Anomie) wrote:

...

On Wed, Feb 19, 2014 at 5:49 AM, Antoine Musso <hashar+wmf(a)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

Matthew Flaschen

25 Feb 25 Feb

11:02 p.m.

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

Brad Jorsch (Anomie)

26 Feb 26 Feb

4:05 a.m.

On Tue, Feb 25, 2014 at 5:02 PM, Matthew Flaschen <mflaschen(a)wikimedia.org>wrote;wrote:

...

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 ;) -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation

Matthew Flaschen

28 Feb 28 Feb

7:09 p.m.

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

Antoine Musso

3 Mar 3 Mar

5:58 p.m.

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. -- Antoine "hashar" Musso

Antoine Musso

5:57 p.m.

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. -- Antoine "hashar" Musso

Erik Bernhardson

8:04 p.m.

On Mon, Mar 3, 2014 at 8:57 AM, Antoine Musso <hashar+wmf(a)free.fr> wrote:

...

* Constants declared with 'const' : we use define()

I've been using const. It's nicer syntax.

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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Tim Starling

26 Feb 26 Feb

4:14 a.m.

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

3706

days inactive

3719

days old

wikitech-l@lists.wikimedia.org

Manage subscription

43 comments

27 participants

tags (0)

participants (27)

AlisonW
Antoine Musso
Arcane 21
Brad Jorsch (Anomie)
Bryan Davis
C. Scott Ananian
Chad
Chris Steipp
Cristian Consonni
Daniel Friesen
David Gerard
Erik Bernhardson
Faidon Liambotis
James Forrester
Jamie Thingelstad
Jeroen De Dauw
Marc A. Pelletier
Markus Glaser
Markus Krötzsch
Matthew Flaschen
Owen Davis
Rob Lanphier
Ryan Lane
Techman224
Tim Starling
Trevor Parscal
Tyler Romeo