Nextcloud server major upgrades, is it worth it?

I agree. I asked the same earlier this year when I seemed to be continually updating Nextcloud which incurs a charge for my client.

1 Like

This is quite easy. I have plans that my customers are happy with and I have different types depending on new feature or keeping the old.

I work with to companies. One for government/enterprise and one for smb or home users.

Send me a pm if you want more info.

I believe everyone missed what the OP was really asking. Is 27 really a major/API breaking update compared to 26 (or 26 to 25, etc.)? Or, is it only feature updates and the wrong version number is being incremented with each major version change?

The question was never, should we update or not. Only, is the correct version number being incremented based on best practice for version tagging?

1 Like

I think I did by pointing the Nextcloud HUB announcements that hightlights the new features compared to previous versions.
For exemple, HUB 3 and HUB 4 brought improved performance and security.
Hihghligted feature in HUB 6 is open source IA assistant etc.
HUB 5, Outlook, Exchange and Teams integration.

I think I did by pointing the Nextcloud HUB announcements that hightlights the new features compared to previous versions.
For exemple, HUB 3 and HUB 4 brought improved performance and security.
Hihghligted feature in HUB 6 is open source IA assistant etc.
HUB 5, Outlook, Exchange and Teams integration.

You did state that, but feature updates/additions are not grounds to update the major version number. Only code base rewrites or API breaking changes are cause for incrementing the major version. Adding to the API is not API breaking, only a feature update. Adding support for Outlook, Exchange, AI assistant, etc., are only additions to the current version. Which means the middle version number should be incremented and the last number to be reset to 0, and the first number being left the same.

1 Like

To address this one more: yes, there were breaking changes. They were introduced during the lifetime of 26 into master but held back from publishing (no 27 yet).

For introduced changes see the docs. You are right, added or fixed things are no concern for a major update. Removed, deprecated, or changed behavior is, however. There are a bunch of these.

1 Like

Dear fellow,

upgrades are not about version numbers, but about version dependencies, stability and security issues prior to new features.
And as code has to be improved anyway, new features and new requirements go often hand in hand in new versions and to meet all these requirements in a weighted manner, upgrade policies are implemented.
For example, Nextcloud 27 is probably the last major version to support PHP 8.0 and below which means code rewriting of things that did already work because outdated PHP versions won’t get security issues fixed anyway.
If version 24 would have to be rewritten to support PHP 8.2, it would be a new version either way and not “the stable stuff” any more.
It is just a wild guess that older versions would be more stable than recent ones.
The process of evolving systems just includes new errors to be fixed.
Your question is in fact the question “why not leave an outdated system connected to the internet?”
Nextcloud relies on several software components outside the scope of Nextcloud developers and has to meet version dependencies.
“Never touch a running system” in terms of upgrades only refers to air gapped systems or at least systems without a standard gateway but not to world widely served web applications.
You might not have gotten satisfying answers because basic experience with system administration gives you the obvious answer as well as the question seems like a lack of understanding.

Kind regards anyway,


1 Like

google “nextcloud changelog” then decide if you want to upgrade. My advice, leave it until there is a minor update after a major update to upgrade

I had rarely an upgrade within the leading version number xx. . which happened without failure.
Most of the time i have to make a new install then anyhow.
Now I changed the underlying OS devuan , to have php 8.2 available. Then I can change (new install) from 24 to 27. Then I stick with 27. to avoid update failures. But I do the 27.minor.patch upgrades . Skipping these upgrades seems also to not being tested.
And dont upgrade from the browser window. One unnecessary level of complexity

The change behave of NC is a PITA for individual users.

For me it generally goes without problems. Then it is no hassle to keep a bit on track with current versions. If you don’t track down what goes wrong during an upgrade and you just do a new install, you have to do it all the time…


I started my Nextcloud journey in June on my Odroid HC4 with DietPi, which was based on fresh Debian Bookworm. I don’t use NextcloudPi, I consider it too heavy and slow on this machine and not everything worked well. I am currently planning to stay one major version behind. Now I am on newest 27.1.2, and I want to upgrade to 28 around the release of 29. It is very important to have the newest security and bug fixes, but I am not IT professional and I need stability as well. What do you think about this approach? Or maybe two versions for stability? :slightly_smiling_face:

You can still follow along with the NextcloudPi release cycle. It is conservative, but they keep within one or two releases.


i think - the official Nextcloud statements, tells it all:

We strongly recommend to stay up to date with Nextcloud to keep your data safe. The minor releases fix security issues that are found through, for example, our HackerOne program. Not doing so can put your data at risk. Update timely and don’t run unmaintained Nextcloud versions. Privacy does not exist without security.
Our security policy is to publicize CVE’s about 3 weeks after public availability of a new minor release. Administrators can then learn more about the vulnerabilities fixed and determine if their systems might have been vulnerable. As malicious actors are at this point more able to determine attack vectors, it is important to have updated before the CVE’s are published.

1 Like


IMHO it’s always a good idea to keep applications updated with new versions as they are released. Nextcloud is no exception since they are continuously adding features, improving performance and enhancing the user interface.

Changes with each version are documented in the change log and or release notes.

And the nextcloud upgrade process is really slick via the web interface and before you even start - you know if all your addons have versions that work with the upgrade. It’s very well managed.

So in short, yes - keep Nextcloud updated with both major and minor upgrades.

1 Like

In all honesty, and with all due respect, I don’t think the frequency of releases or the state of the code are the real issue at all here. I think the real issue is a perception on the part of some users that

  • the Nextcloud organization makes promises regarding new features that it doesn’t keep and
  • it doesn’t listen to criticism, even if it is polite and constructive.

I don’t think it makes any difference whether this perception is correct or not. I think what really matters is the effect this perception may have. It’s up to Nextcloud to decide how they want to deal with it (if at all), but I think a few small changes to Nextcloud’s communication strategy would work wonders:

  • Make fewer promises, and keep the ones you make.
  • If it becomes necessary to postpone or even stop working on a feature because customer demand forces you to prioritize other things, communicate this openly, promptly and clearly to the user base, so they know what to expect.

Is it really about the update frequency and not rather the problems some experience (but not all)? Your browser, how many minor and major upgrades did you do over the last 12 months? I don’t know for myself, because it usually runs in the background when restarting the browser.

They try to do it a bit. Often they drop/add support for php versions or other major changes. Perhaps not all the time and some of the major release could have been a minor release as well.

From the beginning, they decided to have a regular release cycle a few times a year. That is great to push things quickly and the development over the years is impressive.

For a user, I think the actual update and release cycle is less of an issue if the updates work well. It’s more for developers, how can they keep up with changes, how stable are APIs etc.

Agreed. The reality is just that there are conflicting needs and desires. In the end, what everybody wants is:

  • 1 release/year at most
  • but all features and bugfixes they want backported to automatically deployed minor releases
  • and of course always supporting the latest PHP and other platform things
  • and releases should never break

The features and bugfixes people want are wildly conflicting - as we know, some people value Nextcloud only for Groupware (people tell me they don’t use files at all) while others don’t use anything beyond Files and so on.

But beyond what people want, we also have the reality of engineering. If we do bigger releases they break more and are more risky. They also take longer, causing more downtime, due to more database changes. Another factor is platform support, databases and PHP in particular - if we do less releases, users will more often bump into issues with PHP for example. Right now we try to align with PHP versions, so that the latest Nextcloud supports the latest PHP and you can upgrade without having to worry about problems there. Still, as some distro’s are slow, some users are on an old PHP that we can’t support anymore and are a bit stuck. That would get worse with longer release cycles.

If you don’t see what the problem is with PHP, consider yourself lucky - if you have been stuck on an old version of PHP and Nextcloud, and suddenly get a much newer version of PHP and then couldn’t update Nextcloud at all - you DO know what I talk about. It’s a nightmare…

In that regard, we really try to make things easy. For example, hub 6 AKA 27.1 was specifically done in a way that wouldn’t make things harder - it is a very quick and light update, not a big, breaking change. PHP does ˜3 releases/year and we follow that, with the 27.1 being kind of a half extra release so we come to 3.5 releases this year :wink:

Anyhow, I can share tons of more insights, but right now, the ˜4 month cycle with ˜1 year support is the best balance we can find between getting features and fixes to users, keeping releases small, not overloading on updates, aligning with the platforms Nc runs on and working efficiently.

If you have issues with the updates and new versions, my tip: use the Nextcloud All-in-one. I recently migrated my personal Nextcloud from a basic LAMP stack to that, and it’s a delight. 99% of your issues are taken care off and updates are super smooth :wink:

Seriously, check that out.


As an app developer i can assure you that NC major versions come with backwards compatibility breaks.

To rewrite the code base each time would be astronomically more expensive than adding features and bug fixes to the current version.

That is not what a Major version in SemVer means. Having any change that results in previously working apps no longer working requires in a new major version. No “rewrite the code base” needed.

Nextcloud is modernizing its codebase (to PHP 8.x) and moving away from old OwnCloud concepts. That causes a lot of BC breaks. You can see all documented ones here.

To say that you are doing this due to budget constraints is actually contradictory.

No. Since any bc break requires a new major version, it’s actually cheaper to just break things and move on when developing new features instead of introducing some kind backwards compatibility just to avoid a new major version.

Trying to “just add features to the current version” without breaking anything is therefore the more expensive way, since it requires more work. Especially if resources (developers) are limited, it also means less new features as every feature is more effort to develop.


I’m running a normal self hosted instance and from my point of view, the updates themselves are usually very easy. The real issue for me is the lack of updates with all the apps.

IMHO it would be great if Nextcloud moved from a version number only check to a feature based check, so that apps may continue to work as long as the NC features they use still work. Just like Linux syscalls.


3 posts were split to a new topic: Maintaining proper PHP versions of Nextcloud in Ubuntu