I have to question the decision to drop support for PHP 7.4 at this time. Iām aware that itās EOL, but neither Debian nor Ubuntu have official support for it(*), and Debian Bookworm still does not have an official release date.
For software thatās targeting an enterprise customer base being unable to install it on a standard and common Linux disto seems unwiseā¦
(*) yes Iām aware of deb.sury.org, but many enterprises prefer to stick to official repositories
PHP 7.4 is literally end-of-life, because of PHP.net itself.
This includes Debian and Ubuntuā¦ 7.4 is literally dead. You can still run it, but it is done.
āDoneā doesnāt mean ādoesnāt exist anymoreā. As I said, some of the most common Linux installs do not officially support anything beyond 7.4 yet. Theyāre expected to this year, but no firm date yet.
This isnāt a matter of what PHP.net is shipping, but of whatās available in OS distros. You are shipping an āenterpriseā product that is not installable on most common servers used in an enterprise context. Also, bear in mind, most enterprises donāt upgrade to the latest and greatest OSes right away. Maybe a year from now you can get away with dropping PHP 7.4, but is it really a rational business decision to do so now?
Businesses that use this product require it to be stable and installable in stable systems. This is not a good way to support customers.
I work with enterprise customers on a daily basis. All my installations done the last year had been on debian, Ubuntu and redhat. All of them runs php8 or newer.
They have all bought my reasoning that itās stupid to stick with old unsupported pho packages. Even if they are in the os repo.
If more php projects would do this distributions will be forced to update to newer php quicker.
And almost none of my installations the last 5 years on debian, Ubuntu or redhat has been on the distributions deb repo.
Apparently itās all about companies needing LTS-support for their setup, right?
So as everywhere else they could buy LTS-support. Even for NC.
But as you can see there seems to be a certain problem about Distro-upgrades and PHP. NC canāt and wonāt solve that since itās up to those distros solving that for themselves.
And itās not that there was no working NC-version left after NC26 would have dropped support for PHP 7.4ā¦ after the Release of v26 there still is a well maintained v25 availableā¦ at least until v27.0.2 was releasedā¦ (and even after that you could buy support for LTS if youād need it)ā¦ which would usually be around 1 year after release of v26.
Aaaaand why would a company have generally a slow upgrade-process on the one hand but then would upgrade immediately to a new major version of NC on the other hand?
I think itās wrong to making up problems by having 1 user having problems updating their PHP correctly (where millions doesnāt have that problem). I bet and hope that companies would have enough of IT-knowledge to run a successful Php-upgrade for their environment if needed.
btw: donāt you hijack other threads, please? You are welcome to open a new thread for new subjects. I have done that for you this time.
and you might wanna read through this whole Thread here as well, I suppose
Iām closing this thread here right now. If you want to go on discussing it please refer to the thread mentioned above (still waiting on plinss to finish his answer as I can see they are typing one)
NC canāt and wonāt solve that since itās up to those distros solving that for themselves.
Not asking NC to solve distroās having the latest and greatest PHP version. Iām asking NC to take a loot at the environments they expect their users to deploy their product in.
Aaaaand why would a company have generally a slow upgrade-process on the one hand but then would upgrade immediately to a new major version of NC on the other hand?
Companies do stay on older OSes but keep try to keep applications up to date, I work with several.
I think itās wrong to making up problems by having 1 user having problems updating their PHP correctly (where millions doesnāt have that problem). I bet and hope that companies would have enough of IT-knowledge to run a successful Php-upgrade for their environment if needed.
This isnāt a made up problem, and personally Iād have no issue upgrading PHP even if it meant compiling it myself. Donāt make this personal. Itās about companies following best practices and security procedures. Many companies stay on older OSes for a long time. Many companies prefer distro packages over third parties.
Furthermore Debian generally commits to backporting security fixes into older versions. They released a security update for PHP 7.3 just last December. Debian will support 7.4 until well after Bookworm is released. It may not be actively developed anymore, but itās not really EOL just yet.
Frankly, Iāve been seeing NC make a lot of questionable business decisions lately and not actually caring about their customers. If I hear āmove fast and break thingsā one more timeā¦ NC needs to take a beat and make more careful decisions.
it wasnāt meant personal in any way. sorry if that was misunderstandable.
right. Companies. Youāre on the communityforum for home- and maybe small business users. Apart from that: Companies still can buy LTS support from NC.
it IS officially EOL. Thereās no question about that. there are unofficial ways to get longer support for 7.4 but they are ā¦ wellā¦ unofficial (even if they are maintained by the same maintainer for official versions).
I think they do and are quite aware of the situation.
well the officially put out a message about dropping support more than 1 1/2 years before there wonāt be any officially supported version any more. Thatās not really āfastā. Homeusers could plan around that announcement. Bigger companies should buy supportā¦ (I heave heard that there are still supported NC15 versions out and running, just not for homeusers).
OKā¦ so now closing time here. Head over to the other thread if you think you can add on.
(well now I see @stefan-niedermann typing an answerā¦ Iād be waiting on him as well, of course)
Frankly, Iāve been seeing NC make a lot of questionable business decisions lately and not actually caring about their customers
Interesting, for me itās a great decision to stop supporting a stoneage PHP version that is itself not supported anymore to free developer ressources for actually important things.
Please donāt take my comparision too personal, but:
As an āenterprise userā, did you also complain that the latest chrome browser doesnāt support Window 7 or Windows XP anymore? Iām curious, itās well tested stable software - well, no support, but for " enterprise users" this does not matter, right?
Also, as other users described: Install a supported PHP version (it does not have to be the ālatest and greatestā as you stated), use docker or yes - change distro if you want to use the latest and greatest software (instead of sticking around NC25 as long as possible) 
tons of options here.
Debian and Ubuntu do backport security fixes. The latest security update for PHP 7.4 was released in December. http://changelogs.ubuntu.com/changelogs/pool/main/p/php7.4/php7.4_7.4.3-4ubuntu2.17/changelog
Yes, I know backports are done on a best effort basis, and yes, they probably cannot patch everything, but PHP7.4 is not done, not even in a long shot. Since Ubuntu introduced ESM itās technically supported until 2030, because thatās how long Ubuntu Pro 20.04 will get security updates.
So, with that out of the way, what does this mean for the average Nextcloud user? Short answer: Actually, not much!
Should you use PHP7.4 any longer than necessary?
No, you shouldnāt! Unless you absolutely have to keep around some legacy application that only runs with this specific version of PHP.
Should Nextcloud still support PHP7.4 with their upcoming releases?
No, because that would slow down development massively.
What can I do as a user of Nextcloud?
Itās easy enough to upgrade PHP via 3rd party repos or upgrade your distro to a release with a newer PHP version. Yeah I know, Debian 12 isnāt released just yet, but it most likely will be by the time NC 25 goes EOL.
Backport from where? Sure, if there is a known issue and a known fix, they will backport it if possible, but PHP 7.4 doed not even support security support from upstream:
NC 25 still does support php7.4, and it runs out of support in autumn. Until then, you still can run this version in your Debian system, then you can upgrade to the new debian release this year and then also install NC 26. In case there are huge delays on the Debian release, we can ask to extend the support for NC 25 a bitā¦
Yes I know. Debian and Ubuntu maintainers do it, on a ābest effortā basis. And thatās one of the reasons why I said it shouldnāt be used, unless you have to run some legacy application, that you canāt upgrade just yet.
This! Or you can use the deb.sury.repos:. Note: This is not just some random repo on the internet. Ondrej Sury is the official maintainer of PHP in Debian.
The bottom line here is that NC is going to be shipping a product that canāt be installed on an unadulterated install of the latest versions of some of the most popular Linux distros. This doesnāt seem like a good plan.
Switching distros isnāt an option for those maintaining a large fleet of servers and wanting standardization. Using 3rd party packages isnāt an option for those who want to stick with officially supported packages (Suryās packages are not official despite him being the person who maintains the official ones, his packages also have a history of bringing in unwanted dependencies which have broken others.) Docker isnāt an option for those not wanting the extra system overhead or maintenance complexity.
No one is suggesting NC support PHP 7.4 until 2030, Iām simply saying the decision to drop support now is making the latest version of the product unworkable for a significant number of customers. Telling your customers to just stick with an older version is alienating. A product that ships today should be installable on todayās current OSes.
Did you even read the posts in this thread?
Also, If you canāt or donāt want to maintain the dependencies that are necessary in order to run the latest Nextcloud release, you can use Nextcloud-AIO or the official Docker containers. Or if you are running it in your business, Nextcloud provides an LTS release, which was also mentioned somewhere in this thread.
From a userās perspective, it would be nice to have a bit more overlap. Now the problem you face is that you need to update the system and Nextcloud at the same time (if you stick with official packages), since NC 26 doesnāt work with php7.4 and NC 25 doesnāt work with php 8.2.
That is generally something I try to avoid and do the steps separately.
Imagine now there is a huge bug in Debian or Nextcloud, you have to revert the whole setup.
It is clear that you can work around all these things, but it makes it a bit harder for the user than it has to be. At least with good timing and a bit of luck, you update NC+debian at once and you can keep the official packages.
Not sure for the developers, there might be huge benefits if you can cut certain ties with the old php7-branchā¦
I wouldnāt recommend upgrading to the latest version on day 1 anyways, especially if you are using it commercially and / or in a production environment.
Although NC 26 might indeed be an exception from that rule, because NC 25 (Hub 3) had a lot of changes and to me NC 26 feels more like a giant bugfix and maintenance release for Hub 3, instead of a major release in the traditional sense. But thatās just a small side-note, which you should take with a grain of saltā¦ 
well now there has been some more reaction on this than I initially thought.
but all in all thereās nothing new. Itās more or less 1000x the same arguments that has been put out already.
And 1 user who keeps to his point of view.
so nothing more to add. if you want to go on discussion head over to the aboved mentioned thread.
Closing now.
thanks & goodbye