I really appreciate your developer efforts and Iām really sorry you hit issues in the past. This doesnāt mean you will hit same issues in the futureā¦ But your intention goes into wrong direction: the problem is not Nextcloud dropping support of PHP 7.4 the problem is Debian stable ships EOL/EOS PHP version. Stability is the key of Debian philosophy and for this reason this is very valuable and maybe most widely used distroā¦ IMHO the problem is better addressed there. Packages related to security and exposed to public must be somewhat currentā¦ nobody can seriously expect new applications to run ran on 3y old librariesā¦
supporting very very old libraries requires additional effort from application developers:
if you keep supporting PHP 7.4 you remain limited to 7.4 feature set
you canāt use improved language constructs introduced in later versions
you need more testing
and again security suffers
(donāt tell about backports - as mentioned earlier backports are far from complete)
The only problem I can see on Nextcloud side - there is no good supply chain management. At this time we should talk about PHP 8.0 deprecation. NC26 will be the last version which is completely covered by PHP8.0 security supportā¦ NC27 must remove PHP 8.0 alreadyā¦
Just to clarify my position - in my eyes āsupportā doesnāt mean the application doesnāt run on this library - itās more like āthe project doesnāt careā - like no tests, no bug reports etcā¦ if somebody want to use it - do it your own risk. If it doesnāt run feel free to ship some backports but donāt blame the project if something brakes with old libraryā¦
You misunderstood my intention: I do not want to discuss here whether Debian policies are right or wrong. Those are long standing for decades and wonāt change. Iām looking only from the end user perspective here, which do now have the issue, regardless what we think about Debian or how reasonable the decision to drop PHP 7.4 was.
Instead:
Iāll ping you guys for a review, in case you use/used/administered Debian anyway.
We have this long solved for our users, they wonāt face any issues and are also taken by hand with a script for an upgrade to Bookworm. This is for non-DietPi Debian Bullseye users .
No support in fact means that Nextcloud is denying to be accessed, neither via web interface, nor via CLI, which is the only reason why a transition version with PHP 7.4 + 8.2 support would have been helpful: On the roadmap: deprecation of PHP 7.4 - #27 by MichaIng
Itās only about documenting and promoting solutions for admin here, who are stuck because of this, including the risks/pitfalls of each.
you spot the problem very good. The root cause of this gap is Nextcloud dropped support for 7.4 too lateā¦ and this my most important point all the time - deprecation of dependencies must be announced early enough to make the admins and maintainers aware of the upcoming changes and look for solutions. It would not have solved the āDebian issueā jumping from 7.4 to 8.2 but admins would have been forced to find solutions and add 8.0 or 8.1 to their running Debian stable. As we have 3 major actors with different goals and lifecycles the might be no good solution for everybodyā¦
If announcing it early to give admins sufficient time is important, how can dropping support earlier than be right at the same time? The time between announcement and dropping support is important, and if this is too short, either announcing it earlier, or dropping support later would address this . However, I think it was announced sufficiently early in November last year. Given how long Nextcloud versions are supported, even for professional environments without support contract, it should be sufficient time to find a solution without every staying on an EOL Nextcloud version. Leaning about options, their implications and which suites best for the individual case, is what I want to help with.
Having some clear policy about supported PHP versions so that we can know now at what date PHP 8.0 and PHP 8.1 will stop being supported by Nextcloud (given ending support from PHP side is known), is still a good idea.
Btw, I think the issue with Debian stable is a one time case with this release. Debian always starts freezing states at the beginning of the year and a new PHP version is always released at the end of the year. Ondrej (Debian PHP package maintainer) actually wanted to merge PHP 8.0 into Debian Bullseye, but he was a little too late merging it into unstable to go through the regular process for the release team to accept. All other packages need to adapt their dependencies (always a two step transition process on both ends), all needs to be tested a while in unstable etc. Ondrej learned from this which is the reason why PHP 8.2 now is in Debian Bookworm. So in two years Debian stable wonāt have an unsupported PHP version and ājumpā will be smaller from PHP 8.2 to 8.4. If schedules stay the same, this stays true for future Debian releases as well .
I wrote a HowTo about how to upgrade to Nextcloud 26 on Debian Bullseye, using either Ondrejās PHP repository or upgrading the system to Bookworm: HowTo: Upgrade to Nextcloud 26 on Debian Bullseye
Everyone is invited to give feedback, in the hope we have something helpful to give admins at hand who have not so much experience. I aim to collect and update it with solutions for possible issues and maintain it as (community) support thread for the process as well.
.
. However, I think it was announced sufficiently early in November last year. Given how long Nextcloud versions are supported, even for professional environments without support contract, it should be sufficient time to find a solution without every staying on an EOL Nextcloud version. Leaning about options, their implications and which suites best for the individual case, is what I want to help with.
.