@tsteur opened this Issue on June 19th 2015 Member

PHP 5.4 gets security support only until 14 Sep 2015. Source: http://php.net/supported-versions.php PHP 5.5 goes into security support only tomorrow.

Dropping support for PHP 5.3 is planned for Piwik 3.0 and was announced here: http://piwik.org/blog/2014/10/announcing-piwik-will-end-php-5-3-support-six-months-may-2015/
refs #7323 Drop PHP 5.3 support, Require PHP 5.4

If we release Piwik 3.0 after September 2015 (what we will most likely do), it might be worth dropping support for PHP 5.4 as well. Problem is we haven't announced it in advance as we did with PHP 5.3. It would be still worth considering it and maybe we could just announce it and drop support for PHP 5.4 in Piwik 3.X (eg 6 months after the blog post). Users using PHP 5.4 should still be able to use a previous Piwik 3.X version but the problem is they wouldn't receive our security patches anymore. Realistically it will take us 3+ months till Piwik 3.0 will be released so we would still give notice at least some time in advance but 6 months would be certainly better.

This should be part of our security policy but it will also allow us to use new features: http://php.net/manual/en/migration55.new-features.php. I'm not sure if there are eg some Ubuntu LTS versions or so that still support PHP 5.4 for a while?

I know many won't like it and we will most likely wait for another year but I created it though as we will drop support at some point anyway (and if it takes 1 or 2 years).

@mnapoli commented on June 21st 2015 Contributor

+1 The security argument is definitely valid (and some of the 5.5 features are godsend).

@mattab commented on June 23rd 2015 Member

Fyi: this month we saw:

  • 36% on php 5.4
  • 30% on php 5.3
  • 21% on php 5.5
  • 8% on php 5.6
  • 5% on php 5.2 (they will be using Piwik 1 still)

+1 for security argument

Currently still two thirds of userbase on PHP 5.3 or 5.4. It's a lot. Still we can consider requiring PHP 5.5. Let's decide a bit later

What do others here think?

@ThaDafinser commented on June 23rd 2015 Contributor

+1 to drop 5.4 also

@quba commented on June 23rd 2015 Contributor

What about RedHat 6.5 and other Enterprise-ready operating systems that may not have PHP 5.5 in default package repositories?

@tsteur commented on June 23rd 2015 Member

That's what I was wondering in the issue description:

I'm not sure if there are eg some Ubuntu LTS versions or so that still support PHP 5.4 for a while?

Do you know if there are some LTS versions or so that still provide security support for PHP 5.4 for a while? Please comment if you're a user of a LTS version who cannot update. If someone is not using an LTS version of eg RedHat, there should be a newer version available that supports PHP 5.5+ but of course for such users we should give them probably 6 months time to upgrade their system as this can certainly take a while.

if someone wants brand new shiny features...why not force him to upgrade his stack?

Exactly, the problem is more like some important bug and security fixes that they won't get. We usually only maintain the latest Piwik version.

@mattab commented on June 23rd 2015 Member

(FYI: even before we need to take a decision we will anyway display permanent notification in admin screen for PHP 5.4 warning about EOL #8193)

@mahdi1234 commented on June 24th 2015

Debian 7 “Wheezy” comes with regular support until February 2016 and extended LTS until May 2018 for php 5.4

Since Debian 8 has still problems, I'm for sure not the only one refusing to upgrade (systemd and php 5.6 being several of reasons at the moment, but not limited to those only).

@mattab commented on June 25th 2015 Member

some info on Red Hat found at http://blog.remirepo.net/post/2015/06/23/Red-Hat-provides-PHP-5.6-for-RHEL

Stability addicts can keep quiet, PHP 5.3.3 is still the standard version provided with RHEL-6, and 5.4.16 with RHEL-7
RHSCL 1.x users can also keep quiet, the php54 and php55 collections are still there. They even have been updated to 5.4.40 and 5.5.21.
The new rh-php56 collection provides version 5.6.5.
We now have an official and supported way to install PHP version 5.4 or 5.5 or 5.6, beside the system version, without any effect on installed components. Announcement tells the life cycle will be 3 years.

@thomaszbz commented on June 26th 2015

As far as I can see that statistics (36% on php 5.4, 30% on php 5.3) represents pretty much what is going on in the field:

Lazyness aspect:

  • Hosters avoid the hassle of updating PHP on web spaces (never force customers)
  • VPSes have old Kernel versions which are never changed (I'm speaking of 2.6 or 3.2 here!)
  • Major Updates of Linux boxes fail due to old Kernels (I'm speaking of Debian 7 here)
  • users have multiple applications running, which all have their own PHP requirements
  • or they just don't care and stay with Debian 6/Ubuntu 12.04 LTS or even older

LTS Distro aspect:

I guess dropping PHP 5.3 support will be painful and dropping PHP 5.4 will be even more painful. People love their LTS boxes, but what's the benefit if they can still use them just 1-3 years, just because PHP applications become incompatible because developers are keen for new features? In theory, distros will still backport security patches even after original support has finished. E. g. Ubuntu 12.04 LTS should get PHP 5.3 security updates until april 2017...
Personally, I would not rely on that... The point is that most of the PHP 5.3/5.4 code should still run with PHP 5.5 while PHP 5.5 specific code using new features will not run on PHP 5.3/5.4.

Other Applications aspect:

A good point to start investigation is to have a look at the requirements of common CMSes and web applications. E. g. Typo3 CMS dropped support for 4.5 LTS release in March 2015. Users updated to TYPO3 CMS 6.2 LTS hopefully (many did not yet). Now the specs of 6.2 LTS are PHP 5.3.7-5.6, getting security updates until 2017-03! The next LTS release (expected in autumn 2015) requires at least PHP 5.5. They can afford PHP 5.5 because users can stay secure with TYPO3 6.2 LTS/PHP5.3 until 2017-03 (as long as they get security patches for PHP5.3).

A good way to go might be to offer security support for the old stable version (LTS-like). I pretty much like the release cycle of TYPO3 LTS these days.

Personally, I don't care what you decide, I'm very happy with Debian 8 / PHP 5.6. I think I never had a Debian stable which was so "bleeding-edge". Even got Kernel 3.16 for my VPS and now there's nothing to complain ;)

@MagicFab commented on June 26th 2015

This site may also be useful to consider most GNU/Linux distributions support /lifecycles: http://linuxlifecycle.com/

To research specific package versions: http://pkgs.org/

@tsteur commented on June 28th 2015 Member

Debian 7 “Wheezy” comes with regular support until February 2016 and extended LTS until May 2018 for php 5.4
Since Debian 8 has still problems, I'm for sure not the only one refusing to upgrade (systemd and php 5.6 being several of reasons at the moment, but not limited to those only).

I think we can "ignore" it when there's a newer LTS version for a specific distro that provides support for PHP 5.5+ . From what I can see major distros released an LTS version in 2014 and should support PHP 5.5+

I understand that it is a problem when there is no newer LTS version and the latest LTS doesn't provide PHP5.5+. We had similar problem until recently with Ubuntu and PHP5.3 and that's why we haven't dropped support for it earlier.

If we'd drop support in eg 6 or 7 months eg Debian 8 should be a bit more stable by then ;)

@thomaszbz commented on June 28th 2015

I'm missing a discussion which features you actually need from newer PHP versions. You also need to discuss if you actually want to use them in respect of software engineering.

So the question should also be: What's the benefit of using the features of PHP 5.5 and is it worth the new requirement.

Another question I'm missing here is about libraries/dependencies you are using in Piwik: Do you need to update them? How long are they supported currently? Will libraries require a new version of PHP in the next time?

@bolera commented on July 9th 2015

Please add a php version check to the update announcement in the Piwik dashboard and do not announce an upgrade that cannot run on the installed php platform. Instead display the latest update that still can run on that platform and if that is already installed display something like "There is a new update x.x.x, but you cannot install it, because it requires PHP 5.x. Please consider upgrading PHP." And no link to install it. THANKS !!!

@duritong commented on July 9th 2015

Please avoid not supporting any version that is still supported by a LTS distribution (whether it is Debian, Ubuntu, RedHat or CentOS) unless you specifically want to rely on features provided only by newer languages.

Remember: All these distributions provide security backports for the versions they have in their repository and hence saying that these versions are unsecure just because they are not anymore supported by the php-project is not correct.

If you just go by latest greatest just because you feel like, you make your software unusable for anyone who does serious hosting.

@ThaDafinser commented on July 10th 2015 Contributor

If you just go by latest greatest just because you feel like, you make your software unusable for anyone who does serious hosting.

@duritong latest and greatest will be surely PHP7 when Piwik 3.0 is finally released...

Some other projects currently:

@duritong commented on July 10th 2015

There won't be any PHP7 on any current stable linux distribution (Debian stable/CentOS 7), by default (which is what most people want). Unless you plan to release 3.0 in >2years.

@gaumondp commented on July 10th 2015

@duritong , I think you missed the < sarcasm > tag from ThaDafinser...

I think PHP 5.5 will be the next "we're stuck with it" PHP version for many years.

@mattab commented on July 10th 2015 Member

FYI Our current plan is: Piwik 3.0.0 released end of year 2015, and will support PHP 5.4

@thomaszbz commented on July 10th 2015

@mattab sounds good ;)

@robocoder commented on July 11th 2015 Contributor

@duritong: Canonical's LTS releases are supported for 5 years. That is a long time to ask developers to not use features introduced by newer php versions. Ubuntu 12.04 LTS shipped with php 5.3.x and will be maintained until April 2017. Ubuntu 14.04 LTS shipped with php 5.5.x and will be maintained until April 2019.

Since it's looking likely that the next Ubuntu LTS release (16.04) will have php 7, I think the minimum requirement should be the last of the php 5.x series, i.e., 5.6.x.

@duritong commented on July 12th 2015

I'm not asking to support all LTS releases. I am asking to support the versions that are by default (or as in by the distro supported software channels) in the latest LTS versions of the major distributions of the current moment. Meaning as we speak: CentOS/RedHat (atm 7 => php 5.4 or 5.6 using SCL), Debian (stable => php 5.6) & Ubuntu LTS (atm. 14.04 php 5.5).
This will be totally different in 2 years, as there will be new stable, LTS release. So no need to stick imho with an LTS version for-ever.

But this is what you want to do if you want to have people actually using your software without too much annoyance. Because people who have to support tons of systems, want to have stable distribution (just for keeping themselves sane) and telling them to install php from source or from a random repository (with no idea how long it will supported e.g. security wise) is a) not a good idea and b) will not bring you more adoption. And I'm not yet even speaking about Enterprise environments.

@MagicFab commented on August 4th 2015

In preparation for tonight's Piwik Meetup in Berlin, there was a discussion today about LTS support. I presented how Debian and Ubuntu do LTS, possible ways/times to align with such release cycles/lifetime, feedback about Piwik 3 and upcoming changes to update mechanism and implementaiton possibilities was exchanged. A blog post on Piwik.org will follow, I am hoping to have complete community feedback at the meetup and over the next few weeks at other events.

@szepeviktor commented on August 6th 2015 Contributor
@thomaszbz commented on August 10th 2015

PHP 5.5 supports class name constants: http://php.net/manual/en/language.oop5.basic.php#language.oop5.basic.class.class

This a feature which is really great using Symfony components.

Fresh release of TYPO3 CMS v7.4 needs at least PHP 5.5. They make use of class name constants whereever possible. Still, users can remain safe on TYPO3 CMS 6.2/PHP 5.3+ for years.

@tsteur commented on August 11th 2015 Member

PHP 5.5 supports generators as well. They can help to reduce memory quite a bit but haven't thought in detail where they can help us, there will be parts for sure: http://us2.php.net/manual/en/language.generators.overview.php

@MagicFab commented on August 11th 2015

There is now an issue for implementation of LTS in Piwik, I've also opened a forum discussion about it.

@marclaporte commented on August 12th 2015 Contributor

Now that Piwik LTS exists (with support for PHP 5.3), there is no need to be shy about increasing the requirements. Post-LTS versions are a great time to push innovation.

I think it should be PHP 5.5 at the very least (and why not PHP 5.6?)
PHP 5.5 is already somewhat old, and has nice built-in OPcache

Best regards,

M ;-)

@thomaszbz commented on August 12th 2015

:+1: Backed by LTS, we should go for PHP 5.5/5.6. Hint: Ubuntu 14.04 LTS comes along with PHP 5.5 while the next Ubuntu LTS release (PHP5.6?) will be in April 2016.

@mattab commented on August 13th 2015 Member

Since we are introducing Long Term Support LTS release for Piwik #8546 for Piwik 2.X, every Piwik user will have the opportunity to use a very stable Piwik service running on PHP 5.3 or PHP 5.4.

Therefore, we are now seriously considering requiring PHP 5.5 for Piwik 3.0.0. Are there any other thought or opinion about this?

@mattab commented on August 21st 2015 Member

Moving this issue to Piwik 3.0.0 where we will very likely require at least PHP 5.5.

@mattab commented on November 2nd 2015 Member

Adding to 3.0.0-b1 milestone: Piwik 3.0.0 will require PHP 5.5.

@tsteur commented on November 25th 2015 Member

Just a random fact and a bit off-topic: On July 10th 2016 PHP 5.5 reaches its EOL. By the time we release Piwik 3.0 PHP 5.5 might be already no longer supported. Not suggesting we should directly drop support for PHP 5.5 too... it's just a random note since it rather depends on which PHP versions are supported by LTS Linux distros etc

@halfdan commented on December 26th 2015 Member

Big thumbs up to dropping 5.4 for Piwik 3.0! Great decision.

@masteranalyze commented on February 1st 2016

I agree with tsteur,piwik 3 by the time of release,should be compatible with php 5.6 and php 7 especially,as php7 is from now on the future.

Php 5.5 by the time,piwik 3 stable not beta it will be released,it will be OUT OF LIFE,and security can be an problem.

People that wish to remain into the past,can use piwik 2,but i think the future is on piwik 3 and php 7.

Php 7 with Maria Db,haves an great effect on loading things up,much more good and fast.

People that wish to live in the past,they are freely to do so,but i dont think piwik will do progress if its stuck into the past.

And people should also care,more about their security,if they use php version EOL,they are the perfect target!Their choice....

@emirb commented on March 9th 2016 Contributor

To sum it up:

So by the time Piwik 3 is released, Nov 14, 2016 per https://github.com/piwik/piwik/milestones, PHP 5.5 will not be supported anymore.

@tsteur commented on March 9th 2016 Member

Yep. Pretty much the only question is whether most Linux LTS users can update to PHP 5.6 or newer I would say. However, they would still be able to use Piwik 2.16 LTS if they cannot update their PHP version.

There are not too many interesting features for us in PHP 5.6 I think (http://php.net/manual/en/migration56.new-features.php) but it would be still less work etc. not to support PHP 5.5 as well. I presume we will decide in about 4-6 months.

@tsteur commented on August 8th 2016 Member

I think we decided to go with PHP 5.5 for now. I think the best will be to release major releases more often so we will be able to drop support for PHP versions and some of our APIs sooner. We can see in our stats that lots of users are still using PHP 5.5. @mattab correct me if I'm wrong and feel free to reopen.

@mattab commented on August 8th 2016 Member

@tsteur yes it would be ideal if we released major versions a bit more often and regularly! Created follow up issue with a few steps to take to require PHP 5.5 #10380

@mddvul22 commented on October 5th 2016

How is Piwik checking the PHP version for this warning notice? We have Piwik LTS 2.16.5 running on a CentOS 7.2 server. I installed apache 2.4.18 and php 5.6 from Software Collections and tested running my Piwik install with that. Software Collections installs all of this content into /opt/rh. I verified that Apache was using the newer php5.6. However, Piwik still complained that I was running php 5.4. (php 5.4 does remain installed on the server, in its original location. Is there a chance that this version check is not checking the correct php?

@tsteur commented on October 5th 2016 Member

I'd recommend to have a look at "Administration => System check" which PHP version it shows. Maybe it's not actually using PHP 5.6

@masteranalyze commented on October 5th 2016

Check what tster did tolded you,if php 5.4 remains in there as your saying,maybe piwik is using php 5.4 instead of your new php 5.6 installed .

Check if piwik is not using php.ini witch actually is php 5.4 instead of php 5.6.

You can have all kinds of php versions in your web server stack,it does not matter what apache is using,it does matter what Piwik is using there.

You can have an software like wp running on php 7 and piwik running on php 5.4,it can be easily done through server configuration,if you have of course both of those 2 versions.

Check what version of php,is using the software you use,in this case,piwik.

This Issue was closed on August 8th 2016
Powered by GitHub Issue Mirror