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)?
1 Like
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.
2 Likes
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.
2 Likes
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:
- Release Notes | SUSE Linux Enterprise Server 15Ā SP4 for SLES 15SP4
- DistroWatch.com: Red Hat Enterprise Linux for RHLE 8.7 and up
So that leaves Debian where you can workaround by using 3rd party repos to get to 8.0 and up Iād say.
1 Like
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.)
2 Likes
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.
7 Likes
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:
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.sed -i 's/>= 80200/>= 80300/' /var/www/nextcloud/lib/versioncheck.php - 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 (
libssland others) are pulled as well from that repo, which can cause hard to resolve dependency conflicts when you ever remove the repo again.
2 Likes
So donāt remove it then 
Seriously, Iām using the Sury repos since forever, and never had any major issues with it.
In most cases it works fine, but when documenting it here as general solution for Debian Bullseye admins (as we thought about above), also 1% broken systems are a problem, respectively readers of the guide would need to be made aware of the implications.
Are you currently using PHP 8.0 or 8.1, e.g. because you are using Nextcloud 25? Then
apt install phpmyadmin
and see for yourself. Or (in general) you are a Debian Buster user and this summer it will be removed from the repo (it supports only āstableā and āoldstableā, not āoldoldstableā), or you want to switch to Bookworm now, which is not (yet) supported by the repo. Or you install packages/software which require a specific (or max) version of either libssl/openssl/libgd/libpcre/libsodium/libidn/libxml/libzip/libzstd/ā¦ shipped by your Debian repo while Ondrejās repos ships (and the PHP packages depend on) newer versions. Or some ARMv6 RPi admin is following the guide and makes the system unbootable that way (yes it is!). Just some of the issues we were faced with.
Trust me, we installed the repo for some tenth of thousands of admin, and we got, I didnāt count, but let it be 100 related bug reports/support requests (less than 1%) for our ~1.5 man spare time support team, and by chance found some also on other forums, like Pi-hole and also here (if I remember right), usually since admins found a too new PHP version after apt upgrade on their system which broke the PHP applications or at least their CLI (depending on how sockets were configured). And those were only the ones who were not able to solve it by themselves or were not aware of the underlying issue. And of course, who needs to read instructions to install a newer PHP version than offered by Debian, is more likely not able to solve issues without help. So keep in mind the audience we would write the guide for.
I donāt use phpMyAdmin, so no idea if the Sury repos are going to cause issues with it.
So far, Iām only running a test instance on Debian 11, because Iām planing to migrate from Ubuntu to Debian once Bookworm got releasedā¦
My production instance is still on Ubuntu 20.04. Iām running the same instance (in a VM) since I started with Nextcloud (Probably with NC13 or 14). It has since been upgraded from Ubuntu 18.04 to 20.04, and it survived several MariaDB and PHP upgrades. Both from the third party repos of MariaDB and Sury respectively.
However, I donāt do PHP āupgradesā, I usually reinstall it. If everything is documented, this does take less than 15 minutes including configuration. Btw. my documentation is heavily based on Carsten Riegerās guide, with slight adjustments.
This happened once to me, and I just re-installed the correct version.
Yes of course, I can only speak from my own experience. But issues like that can also come up if you are using the packages from the Debian or Ubuntu repos, especially if you are hosting multiple sites with different applications on the same machine / LAMP stack. I guess, these dependency issues are one of the main reasons why Docker, or containers in general, got so popularā¦
As mentioned, in most particular cases it works well, and admins with some experience are able to deal with mentioned issues or avoid them in the first place. But you are not among the target audience of such a guide (you do not need it) and Iām talking about a risk that a statistically small, but absolutely still large number admins/systems running into mentioned issues without the knowledge or self-documentation practice to solve it quickly, if we have some HowTo/guide promoted here.
No, if you run the applications on the PHP version shipped by the official Debian/Ubuntu version, such can never happen (on a āstableā and older Debian and LTS Ubuntu). Package software versions are fixed, only bug and security patches are backported and compatibility between packages is moreless guaranteed, especially when its about such basic widely used frameworks/runtimes/libraries like PHP.
I can see what you mean, and I tend to agree. Nextcloud should probably wait one more release until they ultimately deprecate support for PHP 7.4.
On the other hand, for people who donāt want to bother with such things, there are various alternatives available, like Nextcloud-AIO or the official Docker images, which I think are better suited for most home users anyways.
This doesnāt help people who now have a bare metal install now, data, database and config migration to those appliances isnāt always trivial, and they have various limitations as well, especially being not fully configurable, and the container engine brings further resource needs, complexity and inherently risks, like our Discourse broke down for a few minutes yesterday night after an upgrade because of: Daemon cannot start containers without apparmor Ā· Issue #44900 Ā· moby/moby Ā· GitHub
Someone with limited experience to diagnose service startup issues, search for the right keywords or like me just tries apt install apparmor according to the error log, may be stuck for a longer time.
I donāt think that PHP 7.4 support can be re-enabled easily now, NC26 is in beta already, and reasonably from developer perspective the motivation is absolutely minimal. So I write this more to make you guys aware form end user perspective and about possible issues and topics like this (saw just now) to come up.
Letās look and solve this forward. Iāll use the weekend to write some HowTo about the matter.
Yeah sure, but for home users e.g. Nextcloud-AIO is perfectly fine as it is. They usually donāt need to tweak much. And yes youāre of course right, if you already using it on bare metal, itās not easy to migarte, especially if youāre just a home user, without an IT background, that copy & pasted the commands from some random guideā¦
Sorry but the guy in the other thread, is a bad example. Heās talking about enterprises that donāt want to install third party repos. My first question would be, why is he using Debian instead of one of the recommend distributions like RHEL or Ubuntu in an enterprise environment? And why is he using the community edition of Nextcloud? The enterprises I know are all using RHEL, very few are using Ubuntu or Debian, mostly because some appliance requires it, and all of them have support contracts for mission critical software and for their appliances. To me this sounds more like some small business MSP or someone that offers hosted Nextcloud services, without thinking everything through before he started. Or maybe he is just a home / small business user who thought his statement would carry more weight if the word Enterprise is included.
1 Like
Installing from repo is the way on Bullseye
This is exactly what you are expected to do when running Debian stable. 
1 Like
Yes, you are right, sorry didnāt want to open to can of worms on this issue 
. However, more emotionally than rationally driven issues will appear, so good to have something at hand to link and close the pointless discussion .
Installing what from which repo?
Read what I wrote about potential issues when using it. So I clearly disagree that this is what one is āexpected to doā as an unconditional general recommendation. Upgrading to Debian Bookworm with the little Nextcloud 25 hack I posted above is what, based on my experience, will cause admins less issues. But of course, highly depends on the system setup, other used software, admin knowledge/experience, finally personal preference.
I read what you wrote, but the point of Debian is you are expected to either:
- Stick with stable branch
- Pin packages
- Use repositories
- Change to Testing branch, which is what Ubuntu bases off of
This is how Debian works. As it is a community distribution, there is no enterprise support available (which is why Ubuntu exists).
Absolutely, running a server is a serious commitment. Same reason I have not upgraded to Bookworm yet, but this discussion of Debian stable is not related to Nextcloud. Sounds like you are running into difficulties, which is perfectly understandable. Like @bb77 pointed out, this is a lot of conflation.
1 Like
Iām not running into difficulties myself, but Iām a developer of a Debian based distro (FLOSS/non-professional/spare time project) which offers a fully scripted bare metal Nextcloud installation, similar to NextcloudPi but with ~200 other software options. We implemented PHP 7.3 via Ondrejās PHP repo on Stretch that time, coincidentally when Nextcloud dropped PHP 7.0 support that time. And from the about 40.000 systems with this setup, we are receiving support requests until today. So we are kind off in the middle of software developers and end users, and I do want to use this experience to give people some more at hand than āthis is your problem, deal with itā.
I 
DietPi. Thanks for working on it @MichaIng! I totally lost the thread of you being related to that project and read this as a series of emotional responses as opposed to an actual discussion. Re-opened in the hope there might be a productive discussion beyond what has already been announced and discussed extensively.
Would it be better to have a Diet Pi specific discussion on your forum? Or, can you link to related topics you are hinting at that might add to this discussion. Thanks!
1 Like