So I didn’t notice that upgrading across multiple versions is unsupported and I’ve created deb packages for nextcloud server. Unfortunately one user already tried upgrade which upgraded PHP so there’s no way back - downgrades are not supported by Debian.
I started digging into the code and it looks to me that they are technically possible just weren’t tested? I tried running it in a VM with version.php patched to allow 21->27 upgrade and it did seem to work.
So my question is would it be possible to support such upgrades? Or perhaps could I support them for my users by locally patching the code and properly testing? What’s the proper test procedure? Am I missing something important?
Also note that if I’m unable to support these upgrades then I will probably have to drop nextcloud completely because of how PHP versions change in Debian and how Nextcloud versioning works etc (can explain in detail later, I have to go now).
Just be warned: I am not associated with the server development, so my statements are not official.
The update especially between major releases might require repairing of the database and the file system. If you miss a major version, this might break.
In any way, I see no direct connection between the PHP Version and Nextcloud. Maybe you describe your problem a bit.
@christianlupus if my understanding is correct all the migration code is in core/Migrations/ and the updater runs all of them from the previous version to the current, so skipping shouldn’t happen. Or is there anything else happening?
Here’s the problem with upgrades: In Debian the packages can be always upgraded from any previous package within a single Debian version. So if a user had foo 1.2.3 and then an update provided foo 1.2.4 which the user forgot/ignored/whatever an update to foo 1.2.5 will work. The only way to prevent users from missing upgrades is to put each major version into a separate Debian major version - those cannot be skipped. However Nextcloud major versions are released more often than Debian versions! I had Nextcloud 21 in buster and so I could theoretically put 22 into bullseye and 23 in bookworm.
This is obviously slow but even if I wanted to accept this slowness which would be worse and worse over time, it’s impossible to install Nextcloud 23 in bookworm because the PHP version in bookworm is 8.2 however Nextcloud 23 supports at most 8.0.
The only way around it I can see is to create artificial repositories buster-nextcloud-21, buster-nextcloud-22 etc and force users to manually undergo the same process as if they were upgrading major version of Debian. This is a manual, not-easy process that they currently only need to do about once every two years.
So making Nextcloud support upgrades across multiple versions is the only sane solution I can see. I’m totally willing to put work into testing and debugging these upgrades. I just want to know more about this to do it safely. Hopefully my work could be merged upstream as well so that other users would benefit from it but this is not my main goal.
One more point to consider: NC will provide you with a message in the admin interface that a new version is ready to be downloaded and installed. If an admin decides to do so, it will sideload and break your Debian package manager.
You could do it similarly like the kernel and provide packages for nextcloud25, nextcloud26, etc. Then a meta package might be able to wrap things up… Just an idea.
b) nextcloud FPM poll runs under dedicated user which doesn’t have rights to change the code of nextcloud - only root can.
Oh, good point! While not optimal, it’s at least less bad than my idea.
Unfortunately, it can’t for the exact same reason as above - updating it over two major versions would trigger the same problem, although at least fixable using apt remove nextcloud-server23 && apt install nextcloud-server22