Core: [9.2] Drop PHP 5.4 with the next major ownCloud release?

Created on 7 Jul 2016  路  39Comments  路  Source: owncloud/core

I'd like to start a discussion on the minimum php version requirement for ownCloud 9.2

As of today ownCloud 9.1 can run on PHP 5.4, 5.5, 5.6 and 7.0
7.1 support will be added during the development cycle of 9.2

Question now is if we want to drop 5.4

Pro:

  • Many 3rdparty libraries require 5.5 as a minimum (maybe even soon 5.6 because 5.5 will be EOL soon)
  • 5.5 has some nice language constructs which can allow us to boost some operations (remember https://conference.owncloud.org/conference/oCC2015/program/proposal/66)

Con:

  • Some distros and shared hosters only offer 5.4

If you agree on dropping 5.4 - please add the :+1: emoji
If you dont -> :-1:

Thanks a lot!

discussion

Most helpful comment

Pro:

Allows an update of SabreDAV to 3.1 (https://github.com/owncloud/core/issues/22724) which includes http://sabre.io/blog/2016/validation-changes/

All 39 comments

More radical idea: PHP 7.x only!?

PHP 7 not out of the box in Linux distro. Also need to check what shared hosters provide.

Also consider that some people might be running other php web apps on the same server which might not be PHP 7 ready.

I think 5.6 as min is the better choice.

I think 5.6 as min is the better choice.

let's do this in a second poll

PHP 7 not out of the box in Linux distro. Also need to check what shared hosters provide.

Except you run ArchLinux 馃檲

JFYI: php 5.5 EoL is on Sunday (10th july) http://de2.php.net/supported-versions.php

Also Ubuntu 16.04 with PHP7 works fine and setup is very easy. Very good example of a nice distribution.
I consider it even dangerous to "support" outdated versions of infrastructure. At least recommendations need to point to the best options available.

Pro:

Allows an update of SabreDAV to 3.1 (https://github.com/owncloud/core/issues/22724) which includes http://sabre.io/blog/2016/validation-changes/

and not a single vote against... :wink:

Somebody will come with: I still have my Ubuntu 12.04 and php5.4 in the basement :smile:

and not a single vote against...

If you want some, I can get you some 馃槈

Kill 5.4, kill 5.5, go 5.6 minimum.

Con:
Some distros and shared hosters only offer 5.4

Probably also some NAS systems will have issues with dropping 5.4 support as they are often lacking behind with the PHP versions.

But when having a look at: https://github.com/owncloud/core/wiki/Maintenance-and-Release-Schedule they still can use oC 9.1 till 2018-02

But when having a look at: https://github.com/owncloud/core/wiki/Maintenance-and-Release-Schedule they still can use oC 9.1 till 2018-02

this will exactly be the point. In case one cannot update to 9.2 - stay with 9.1 until Feb 2018.
This should be acceptable

I suggest selecting two; one older long term supported PHP package (5.4?), and also support the newest PHP7. Pick a "long term release" PHP and keep following the latest, drop support for everything else. Do some research into what versions of PHP different popular distribution releases at different version levels support. Build a table, make an informed decision, don't go with "popular opinion".

I apologize for this being so long. This PHP question is part of a larger issue and can't be over simplified to the level of this question; what PHP to support? without a detailed explanation for why?

I'm ambivalent on this PHP issue, because I run a lot of server applications used for my own electronics and software development. Switching or upgrading a fully loaded server is a non-trivial task unlike upgrading a trivial server installation (like most server developer scenarios). Bottom line for this story is chasing the latest upgrades wastes a lot of time I don't have, and I doubt I'm alone. My attention needs to stay focused on my other development, and I need Owncloud to work with little fuss, or I can't upgrade. Here's the longer explanation.

Until a month ago I was running OpenSUSE 12.2 x64. Everything was running fine and I had enough free time to manually install an occasional security patch. It had PHP 5.5 running before Novell dropped support for 12.2. I decided I wanted to include BugGenie in my infrastructure to add GIT support to my issue tracking. BugGenie, like many apps these days has "requirements". The one my 12.2 installation couldn't support was "phar" to run composer.phar, something which appears to be supported out of the box in Ubuntu's distribution. Novell apparently did more than drop support, Novell removed existing 12.2 update packages from their server. I discovered this when I downgraded PHP to 5.3 for phar support, then tried to return to PHP 5.4/5.5 for operation. Many packages don't support running PHP < 5.4. So I looked into upgrading OpenSUSE and discovered that since Microsoft gained a bigger say in development at Novell, Novell distributions now have 6 month-1 year support, as opposed to 2-3 years support offered earlier. Since 12.2 was not only no longer supported, but actively sabotaged by removing 12.2 update packages from the server, I was left with a broken server installation. This sort of "end-of-life" thinking produces a lot of non-productive support work for me and is why I originally left Microsoft's desktop solution(s) and switched to Linux desktop computing. If I have to spend significant time becoming an "expert" in PHP, Perl, Python, Ruby, C, C++, and numerous shell scripts to keep up with configuration changes in a large number of packages, it isn't a good solution.

In looking for alternatives, Ubuntu Server with Ubuntu Desktop 16.04 LTR appears to be the answer to my dilemma with 5 years of long term support. I decided if OpenSUSE was going to cost me that much work to upgrade, I might as well spend the same effort switching to a product which is supported longer term. I can't play "crack the whip" so a company/developer can maximize their decision making flexibility to be "quick on their feet", and "maximize short term profits". i.e. play victim to short term thinking, over simplification.

My new Ubuntu installation wants PHP7 applications. My now defunct OpenSUSE server installation would have been happy with PHP 5.4 or 5.5. OwnCloud 8.2 ran fine with very little effort on OpenSUSE 12.2 x64 PHP 5.5. I am just now after 2.5 weeks of conversion effort at the point where I'm trying to install OwnCloud 9, or 8.2 under Ubuntu 16.04 LTR. I think developers are going to see more long term support OS's, like CentOS for the majority of the market which needs applications to be as easy to install/use as any of consumers other appliances. This means limited number of fixed versions with security patches.

BTW, I'll point to WebIssues as an impressive example of a great, easy to install and use MySQL/PHP app. WebIssues installs with no fuss under OpenSUSE 12.2 and works under PHP5.3/5.4/5.5, and Ubuntu 16.04LTR with PHP7, and supports desktop and mobile displays. OwnCloud MySQL Backup/Restore procedures worked flawlessly for migrating WebIssues MySQL database to the new server installation. This fits with my expectations for all packages.

The end user needs application upgrades and changes to take less effort to accept in increasingly complex and long term legacy environments.

OwnCloud is a killer app, but needs work to make installation and operation less problematic, and part of this is working with different PHP versions supported by different distributions. I consider this issue more important than any shiny new "feature".

@craigarno I think you're missing that PHP 5.4 already reached end of life 10 month ago:

https://secure.php.net/eol.php

Sure, there are still some distros out there trying to backport security and bugfixes to such an EOL version. But there is absolutely no guarantee that every security or bugfix gets backported leaving you vulnerable to bugs and security issues.

Dropping PHP 5.4 support in oC 9.2 would mean that support is dropped 14 month after the EOL of PHP 5.4. Furthermore users are not enforced to upgrade to 9.2 until 2018-02 which means there is a timeframe of 29 month since the EOL of PHP 5.4 to upgrade to a recent (and sane) PHP version. Personally i think this should be handle able if you want to run a secure web application.

@RealRancor I'm sure you are partially right (good link BTW, thanks).

I think the real question is what are OwnCloud customers and potential customers running, expired, unsupported, or not, and should what they're running be supported with newer and/or older stable releases? How many customers are still running with EOL PHP 5.4? Ever looked at how many Microsoft customers are still running XP? Or Windows 7? The numbers are large. Ever wondered why? There are real reasons and it isn't because customers are lazy, or cheap.

In this context, my answer is older systems don't need to run "newest" releases. In this context drop 5.4 for 9.2.

The way packages like Asterisk appear to handle this is they support "long term releases" (LTR). This is why I run Asterisk v11 LTR instead of the latest v13. Asterisk 13 breaks my setup with my current configuration and will be around for a relatively short time before breaking my setup with its replacement [Asterisk 15?]. Asterisk 11 is an LTR release and gets bug fixes only, and I suspect changes to allow it to compile on systems with newer GCC compilers. I run a lot of different packages like this to get the functionality I need, and I don't have time to stay on top of all of them, and continue doing other productive work. Nor do I have the money to hire someone to do this for me.

I can agree with only supporting the latest releases in the latest environments. This still doesn't address older stable customer installations.

I think it would be safer to say we aren't yet seeing eye to eye, as I don't think I'm missing the point. I certainly see the point you want me to see. As I said, this issue shouldn't be oversimplified.

Does accurate data for what OwnCloud customers are running -today- exist?

  • OwnCloud version?
  • PHP version?
  • MySQL version?
  • Web Server package and version?
  • OS Distribution (Windows, OS X, Ubuntu, CentOS, OpenSUSE, Slackware, ...)?
  • Kernel version?
  • Can this data collection be automated with voluntary customer opt-in? (Some customers won't be able to participate for varying reasons and need the ability to opt-out, even if this means not being counted for "support").

Without this information we can argue and dispute each others points based on our experience and opinions for a long time.

Personally i think the developers of a web application shouldn't be made responsible for the laziness of users to upgrade to a sane and recent OS distribution. If that is followed we wouldn't see any progress at all and probably still would have PHP 5.2 around.

Sure, this could be partly solved by having a LTS version with PHP 5.4 support. But that probably needs a separate discussion / issue created.

I wouldn't make a decision about what LTS will support without data. Sounds like you don't have any.

The overwhelming majority of major PHP projects have set PHP 5.5 as their minimum version in the last year. (Drupal, Symfony, Zend, etc.) PHP 5.5 support ends in 2 days. The only notable exception is Wordpress, who doesn't believe in dropping a PHP version until they've confirmed they can't even find it in the wild. They're the outlier. I'd recommend a 5.6 minimum, or maybe even 7.

Disclaimer: I'm just an ownCloud user, but long-time PHP developer, Drupal developer, and community trouble-maker. :smile: I ran the GoPHP 5 initiative years ago (that killed off PHP 4).

Also of note, plenty of hosts offer PHP 7 support: http://phpversions.info/php-7/

Disclaimer: I'm just an ownCloud user,

Same here. :-)

And i'm just pointing to https://statuscode.ch/2016/02/distribution-packages-considered-insecure/

Honestly, if some one is running PHP 5.4 on 2008/2 he still can also run ownCloud 9.1 and just don't update it to 9.2. Its naive to think that those systems running PHP 5.4 are getting all bug and security fixes backported so you can also just run the latest 9.1 with possible security vulnerabilities and bugs.

Disclaimer: I'm just an ownCloud user,

Ditto. Except _as a user_ I have made minor contributions in the past and learned great things about OwnCloud from a helpful developer or two to get my setup running.

support debian wheezy LTS. dont break with this userbase unless you have good reasons to do so.

Debian wheezy is on 5.4
But keeping these Users on oc 9.1 should be enough

@stefanux
Debian Wheezy reaches EOL at 31st May 2018

https://wiki.debian.org/LTS/

so no break with this userbase is done as that user base can stay on oC 9.1 for at least 2018/2

You should ask Hosters, Enterprise Customers too. IMHO large deployments are depending on their Distribution and SLAs. So what's about SLES, RHEL und Ubuntu LTS for example? I don't have a clue how those manage packages like php and EOL Upstream scenarios. OwnCloud on those distributions has been a pita as its very difficult if not impossible to install it without adding 3rd Party repos risking support of your distribution SLA. I think its by far more complex than a "should we drop..." question (as some posts above mention),
Are there guidelines for ownCloud apps? I don't think so. Unique design/theming, additional software requirements/used versions should be handled by this. It sucks needing to stay on a buggy app because one couldn't upgrade to ownCloud 9.0 because the upgrade path from 8.2.x to 9.x is still risky/buggy.
Just my two cents.

Even Debian Jessie has PHP 5.6. People who still run wheezy can probably live with OC 9.1. If they want to update OC they also need to update the distro.
People with outdated hoster might suffer, but I think ownCloud's user base is big enough to pressure some hoster to update.
So, YES drop it. Might drop 5.5 as well.

Haven't read the posts, I vote YES.

EDIT: Sorry, should have read the posts.

Btw, Ubuntu 16.04 Server FTW.

馃憤

Haven't read the posts, I vote YES.

Weird way to take decisions :smile:

馃憤

Weird way to take decisions

Haha, the subject said everything I needed to know. :)

Voted against it for Redhat 5 and 6 users, e.g. Redhat 6 EOL 30 Nov 2020, and who wants be stuck with OC 9.1 so long....

Btw, I just knew about this discussion by coincidence, representativeness of the vote result is in doubt.

and who wants be stuck with OC 9.1 so long....

The main question is who wants to be stuck with such an outdated distro like Redhat 6 so long but wants to run the latest available version of a web application? That makes no sense to me

The main question is who wants to be stuck with such an outdated distro like Redhat 6 so long but wants to run the latest available version of a web application? That makes no sense to me

Not EOL=Not outdated, especially for companies who bought it and can't switch easily as everything like infrastructure and existing applications are based on it. For them, sure it would still be nice to have access to the newest OC, no question about that...

Not EOL=Not outdated, especially for companies who bought it and can't switch easily as everything like infrastructure and existing applications are based on it. For them, sure it would still be nice to have access to the newest OC, no question about that...

I know one explicit case in a bank where the php version requirement change from oc7 to oc8 did finally give the operator the chance to upgrade the operating system. He was pretty happy to finally have a chance to get rid of RHEL5 and upgrade to RHEL6.

The same thing will happen in 2018+ with 9.2 then.

Just to make sure everybody has the same picture - we are discussion to even skip php 5.5.
Please join the vote: https://central.owncloud.org/t/kill-php-5-5-as-well-for-9-2/866?u=deepdiver1975

Not EOL=Not outdated,

PHP 5.4 is already EOL as stated a few times in here. And for the "Not EOL=not outdated": It is outdated and you can't expect that the newest web applications are running on such environments.

Case closed. 5.4 and 5.5 have been dropped

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings