In an ideal world you are right. But people and organizations have a variety of reasons why they don’t run the latest version and dismissing their realities might not be helpful. It is common to be blocked by a lack of resources (time, money, knowledge) and a need to prioritize is experienced. This is why we try to understand these dynamics and why I would like to encourage people to talk about their constraints. Maybe then we are able to come up with practical solutions like the ones earlier mentioned about the Debian release cycle.
I know the situation you describe… but there are too many evil actors on the internet who permanently try to attack and exploit vulnerable system. Today there is definitely no excuse to expose a system with end of support modules to the internet. I’m not a hardcore security fetishist who recommends to install patches immediately, I always recommend to wait a little before updating production but I always recommend everybody to install patches short after release as soon it looks almost stable. And here we talk about pre-previous version of a framework driving one of most important applications in your network… 7.4 was released 3 years ago and stopped active support 11 months ago… If you don’t find time to upgrade your system within this time frame maybe you become less busy when you system got hacked, vanished and all you data is on sale in the darknet…
I’m not sure I follow, how do you get 13 days? 7.4 support may be dropped in 26, which will not be out before several months.
If you want to know PHP versions EOL dates, please refer to the PHP project, which announces them several years in advance: PHP: Supported Versions
Debian Bullseye Stable 11 uses PHP 7.4 link . It is still the Stable Debian release for all production Debian servers until middle of 2023. And then you can use Debian Bullseye OldStable one year and then Debian Bullseye LTS another year.
PHP 8.1 link is only in Debian Bookworm Testing/Sid 12. Of course you can always include PHP 8.1 as a third-party source.
This would have been way too agressive and would have made Nextcloud hard to install on a lot of setup.
There is no reason to drop support for PHP versions before they go EOL in my opinion.
this is absolutely true, but you should not only consider release date but also take into account EOL of the Nextcloud release as well. NC23 becomes EOL once NC26 is released, which is definitely far behind 7.4 EOL. There is no good reason to support an EOL framework in my opinion.
I have no idea how Debian plans to address security issues - the statement above applies there as well.
But I’m using the Sury repo anyways, so when it comes to PHP, I’m not dependent on the Debian release cycles or any backports.
Btw. Those who do not want to include third party repos as a matter of principle should make an exception here. Ondrej Sury is also one of the maintainers of PHP in the Debian project. So I think he knows what he is doing.
Yes, but many distros—Ubuntu, for example—do indeed backport security fixes for 5 or 10 years. So the situation is not always as dire as you paint it here.
Therefore a middle ground may be desirable. I trust that Nextcloud will find the right balance as a project that is infamously fast-moving.
yes they do. the question is how much they do. If you follow the Debians policy provided by bb77 you will find only very very bad security issues will be addressed by Debian (which is one of the most serious projects IMHO). this slightly improves to original 7.4 but it will never compare with the current actively maintained PHP version.
But the more important question is - should Nextcloud support outdated PHP and other dependencies (I would widen it to OS, database etc. as well) - I would strongly argue that they should not. Even further I would recommend align the end of support of specific component with NC roadmap - in this case PHP 7.4 should have been deprecated with the earliest NC version supported on 28. Nov 2022. I think it’s a good habit to mark components as “deprecated” once the upstream reports deprecation. It doesn’t mean you drop it completely but people need time to upgrade such important components as PHP - so deprecation notice 11 months ago would have been at right time - so Nextcloud could completely drop 7.4 support with NC24 - which is expected to remain supported until Spring 2023 - potentially running on insecure PHP version.
I really appreciate deprecation of PHP 7.4 now and I hope to see deprecation of PHP 8.0 soon - which stops active development in Jan 2023 - I would be disappointed to see PHP 8.0 support in NC26…
The question here is not only if it is secure enough for your system - support of specific libraries, requires additional testing, sometime additional code - early deprecation saves dev resources and allows admins to prepare. If admins decide to keep old versions - their choice, there are still people using Windows XP and connected with internet - but a vendor should never ever support a component without active security patches.
Just in case: who you would blame if some security bug in PHP results in successful Nextcloud instance hack?
Next, probably the Linux vendor. But if I’m going to list a chain of entities at fault, Nextcloud is going to be pretty low on the list if it was just a fundamental flaw in PHP.
You do understand that if we applied a policy as strict as what you are suggesting (a Nextcloud version would drop support for any PHP version which is EOL before this Nextcloud version is), Nextcloud versions would only allow one PHP version, and some of them may even support no version (Enterprise release are supported longer)?
A difference between “deprecation” and stop/drop support is very clear to me. good management of dependencies is what I expect from professional product (buzzword “supply chain”) - early support of current versions and early deprecation and clear communication when dependency is going to stop working.
While writing this post I realized there seems to be no common sense about EOL (“end of life”), EOS (“end of support” or “end of sales”) terminology and what does the abbreviation mean and which comes earlier.
But independent of the wording product lifecycle always follow same phase-out schema: first the product stops active development but continue to receive security updates for some period - this is the time when relying vendors like Nextcloud should transition from older to new versions supporting both… On the PHP roadmap this point is the transition from “active support” to “security support”. “Security support” phase of PHP 7.4 was 12 months long and NC shipped 3 major version during this period - definitely more than enough time for every serious sysadmin to upgrade PHP. Once the product does not receive security updates nobody should use and support it (=drop support).
Good proactive management of dependencies does not only react to EOL of dependent product but also aligns it with own lifecycle (with a goal to avoid supported EOL dependencies in the future). Nextcloud docs allready provide “(recommended)” statement for PHP 8.1 now… which emphasize this is the future safe way. Additional “(deprecated)” remark would clearly signal the need to migrate from an outdated version soon.
Thanks for the clarifications. I think we’re getting closer to a mutual understanding.
@wwe earlier it sounded like Nextcloud should have stopped working on 7.4 already in previous versions. Now I see that you are only talking about marking them as deprecated.
From looking at the system requirement docs of previous versions my impression is that the policy is:
Recommend a php version that will be supported until EOL of that Nextcloud version and is well tested enough.
List the other versions that Nextcloud still runs on.
One could add a (deprecated) to older versions. But i think it might be more meaningful to add the EOL date. That way people could tell if they still have some time to upgrade or EOL was already reached.
update - never mind the rest - i was confused. In particular because PHP version support differs a lot between versions. So you don’t gain much by using PHP 8.0 instead of 7.4 - but you gain a lot if you get to 8.1.
So just checked the distros with enterprise versions in mind, namely SLES and RHEL, and at least on newer service pack releases PHP >=8.0 is a given according to:
THX for the early notice - i’ll be even more conservative with upgrading to nc26 then.
I think Debian stable is still one of the most widely used and important distros out there that needs to be (fully) supported w/out any 3rd-party repos.
Where i work, the migration (of a couple of hundred servers) from SLES to Debian is almost complete and all SLES-subscriptions have been cancelled by the end of 2022. i still run a couple of them because of some individually bought enterprise application and that one requires SLES12, so all those Ks of €s for the support-subscriptions are just wasted (and most likley Nextcloud couldn’t even be installed on them). We’re in the process of migrating that to Debian now. All hosts serving stuff to the web run Debian stable; a lot of them with php.
So while i understand that Debian stable may seem a little slow or conservative at times, i am quite certain that the motivation for this has proven viable in the long run (and i would like to see it being supported for as long as possible.)
A short update to my above statement, the decision has been made to drop 7.4 support for the upcoming version Nextcloud 26.
This is to give (app) developers clarity and not have a limbo state on the decision where arbitrary, 3rd party library dependencies might force our hand to drop 7.4 last minute before the release (or shortly after).
I am aware that some people would love to see a more conservative take yet for such scenarios you are free to stay on the former version for the time being (Nextcloud 25 in combination with Debian) which would follow the “conservative scheme”.
Even if you are not yet planning to pick-up Nextcloud 26 right away when it is out it still makes sense to get your environments to PHP8 since it’ll bring performance improvements from a runtime environment perspective.
On a general note Nextcloud did drop support for EOL PHP versions in the past already but as a starter with opening this forum post we are working on improving the communication aspects of such tech-stack aspects for administrators as well as (app) developers.
I know that is basically no chance to have the decision reverted, respectively deferred for one version. But just to mention what we just became aware of:
For Debian Bullseye users it is currently impossible to upgrade either Nextcloud to 26 or Debian to Bookworm the regular way. They are basically stuck.
Nextcloud cannot be upgraded to v26, because it requires PHP 8.x while Debian Bullseye provides PHP 7.4.
Debian cannot be upgraded to Bookworm, because it provides PHP 8.2 which is not supported by Nextcloud 25 yet.
With PHP 7.4 they cannot upgrade because Nextcloud 26 doesn’t support it anymore, with PHP 8.2 they cannot upgrade because Nextcloud 25 does not support it yet, so that the updater cannot even be reached.
Which way around it is turned, either Debian made one PHP jump too much, or Nextcloud supports one PHP version too few to have Debian Bullseye users unstuck.
Two way to get unstuck:
The one I much prefer, after having Debian upgraded to Bookworm and PHP 8.2:
sed -i 's/>= 80200/>= 80300/' /var/www/nextcloud/lib/versioncheck.php
Nextcloud 25 works fine with PHP 8.2. It throws some deprecation warnings, but we anyway do this only once to get to the updater to Nextcloud 26.
Install PHP 8.0 or 8.1 from outside the Debian package repository, e.g. from Ondrej’s PHP repo. But I wrote above that it can cause a lot of long-term trouble as essential system libraries (libssl and others) are pulled as well from that repo, which can cause hard to resolve dependency conflicts when you ever remove the repo again.
