Nextcloud has supported PHP 8.0 and newer versions for some
time now, and we strongly recommend you move to a newer version of PHP.
Version 8.0 is already out of active support (!) and has only 7 months
of security updates left. Nextcloud Hub 3 (25.0.x) deprecates PHP 7.4
but still works with it. We strongly recommend you use PHP 8.1 or newer.
Our Hub 4 release has dropped 7.4 support while introducing support for
PHP 8.2.
Debian 11 Bullseye is the current version of Debian. It uses php 7.4.
Debian 12 has 8.1 And earlier Debian versions can use surys php versions. (Which is recommended for most systems)
You can still use NC 25 for the moment (until Oct 2023). The new debian version is expected later this year (probably earlier than the drop of support of NC25).
Debian 12 is not yet production ready.
There is no need to go to Sury versions. The Debian project is
supporting 7.4.
Dong non-standard stuff is fine for people playing, for hobbyists and
for corporates with big testing and support teams, but with a production
server that has people’s livelihoods depending on it, a more cautious
approach is a smart move.
It is no problem running PHP 8.0 and 8.1 on Debian 11, using the Sury
repository.
@all:
Just FYI, in case some of you didn’t know: Ondrej Sury is the maintainer for PHP in the Debian project, so I think he knows what he is doing, and i see no problem using his repo on Debian.
Unless, you want to use NC26 
Yes it’s more work and ideally you would set up a test server where you first try out how everything behaves before you roll it out on your production server. .
Caution is always a good thing. That’s why running a test server is the “smart move”, regardless of whether you use third party repos or not, and reardless of whether you are a large enterprise, a small shop, or a home user.
PHP updates from third party repos are by far not the only thing that can go wrong. Therefore, it is definitely a good idea to perform any larger changes and updates on a test server first, and only if everything works as desired, apply them to the production server. Otherwise you will almost certainly experience downtime at some point.
Long story short: At the end of the day there is no right or wrong here. Both options, staying on NC25 and waiting for the release of Debian 12 or using the Sury repos, are perfectly valid ways to go. In both cases, however, you should test major changes before rolling them out on the production system… Especially when “people’s livelihoods depending on it”.
I can add that red hat has the same issue with old php. To use any proper php you have to add remi repo.
Oh, there is clearly a wrong answer here. The wrong answer is to drop support for the current version of Debian. And this is not the first time Nextcloud have done it.
The solution is simple. Stop using nextcloud.
“probably” Very reassuring, I don’t think.
If you need guarantees, buy support from the Nextcloud GmbH, then you’ll have access to LTS releases.
There is a saying in German: “Reisende sollen man ziehen lassen” oder “Reisende soll man nicht aufhalten”
Translation: Travelers should not be stopped. Menaing: whoever is determined to do something should do whatever he or she thinks is right
Btw. Today it was announced that Debian 12 is scheduled for release on June 10th.
There is another expression in German: Totschlagargument.
I don’t see it as “Totschlagargument”, but rather as my honest opinion. I don’t need to discuss principles here at all, and I don’t want to do so.
I have tried to show options of what could be done (Sury Repos), and what in my opinion should be done (test environment). If none of that doesn’t fit for him, that’s just the way it is… ¯\_(ツ)_/¯
IMHO, all reservations that can be asserted against Ubuntu PPAs or Debian DPAs do NOT apply to Surys repos. He is the rock in the surf when it comes to stability and continuity. Even with the latest releases, I use its repos as soon as they are available, not only for php but also for Apache2 and/or nginx and am therefore not dependent on the release policy of a distro. or ESM support for Ubuntu etc. That remains manageable and my “inner Monk” has never been bothered by it.
There was a discussion about the php support on one of the github issues. For all the community usage, it was considered valuable to have a supported NC version for the current debian release. Normally, if they schedules are as expected, there should be no problems. If there are delays, it would be great to adjust the support lifetime from NC 25 a bit. However, I neither Nextcloud nor a developer, so I can’t promise anything,
Ubuntu uses newer versions of php (as a distribution close to debian, but others distris have newer php versions as well) and unfortunately, Nextcloud relies a bit on new features of php. If you want to stick with debian, there are 3rd-party packages (more or less widely used), some containerized version where you have more control on the dependencies, …
And if it is so professional that you need a certain version to work with NC, there is extended support for NC 25 beyond October this year.
you are wrong I’m sorry. Support for NC 26 is planned for 2024-03 which is 1.5 years after PHP 7.4 end of security support. Running “production server” connected to the internet using software lacking security patches for many months is the real problem… you can follow details in this thread On the roadmap: deprecation of PHP 7.4 but the fact is Nextcloud supports PHP7.4 way too long… they should have stopped support with NC25 to align with stopped end of security support by the end of Nov 2022…
But if you want to you can keep using NC25 with PHP 7.4 until 2023-10 which gives you more than enough time to upgrade to the next Debian version…
the issue will repeat in a year or two as support for PHP 8.1 ends in 1 year, 6 months (25 Nov 2024) but hopefully till the there will be a better solution for Debian users then…
The Debian project still provides security support for 7.4 and will do until after the next version of Debian is released.
Basically, Nextcloud isn’t really compatible with the ethos of Debian.
This conversation has reached a point of being over. Points made are all fine. Closing this to avoid the conversation devolving.