An annual release within majors is one of the most common methods for admins to keep stable machines running Nextcloud: they will wait a couple releases for the sake of stability. Please consider embracing an annual release for your user base, in terms of documentation or even a different selectable option besides stable. NextcloudPi offers such a thing already, so it is definitely something that can be incorporated. I think the company assisting in this process is worth considering.
I don’t mean enterprise, but I do mean making the update process smoother when the system is upgrading across the maximum number of supported major releases (3).
Seriously, the major update every few months is not quite working currently. Perhaps Nextcloud as an organization does not have to do this, so much as the documentation and update options can be refined to clarify exactly what is needed when a user moves from their existing release to the current release.
Thank you so much for considering. This also relates to suggestion #48178
This update process also applies to admins who forget to update and then scramble to find what has changed on the php/web server/component end that they must address to upgrade each major release, one at a time.
In a video presentation of Nextcloud 31 (Hub 10) (unfortunately I couldn’t find it again) it was said that a large part of the development time is used to fix bugs. I think you are doing the developers of Nextcloud an injustice. But yes, there are also some mistakes. However, this is often due to the fact that it is free software that is largely programmed by volunteers. With commercial software, certain components or apps would probably simply be discontinued rather than continuing to offer them in an outdated and buggy form.
But you can learn how to use Nextcloud over time. For example, it makes sense not to use Nextcloud 31 (Hub 10) yet, but rather Nextcloud 30. In addition, you don’t have to use every Nextcloud app on productive systems. You should also run a test server where you can try everything out first.
That’s only partly true. You have to understand how open source programming works. For most people, it is a hobby and they programme whatever seems interesting. It’s a bit like OpenStreetMap. Only the areas where there are mappers are beautifully mapped. It’s less about how important the area really is. And it is ok if a mapper only maps vending=excrement_bags. For people without dogs, this may seem pointless. Perhaps even for people with dogs.
Don’t confuse the development cycle (which is a new major every 4 months) with the upgrade cycle you need to use on the deployment/ops side.
The only important updates to deploy are:
maintenance releases (x.y.Z) [every 4-5 weeks]
new majors when the major you’re on reaches end-of-support
Each major is supported for at least 12 months. There is no need to upgrade to a new major release just because it’s released. All supported majors receive the same critical bug fixes.
Exactly. At some point, of course, you have to switch to the next release. Companies tend to switch later, as brand new releases often not only have many new features, but also additional bugs.
@Sanook
The next maintenance release e.g. Nextcloud 31.0.1 was shipped. Maybe you can upgrade your Nextcloud.
Yes, that’s true. It is a common method to develop multiple variants from the same product in order to optimize marketing.
I am not in a position to assess the market, so I cannot judge whether it is reasonable and appropriate to release a new version every three months.
However, this creates the need to backport changes to older versions, meaning that each adjustment has to be implemented three times – both for new features and for bug fixes whenever a maintenance release is issued.
From my perspective, this unnecessarily ties up valuable resources, as every change has to be implemented three times.
Wouldn’t it be more efficient to fix existing issues first before developing new versions? Otherwise, existing problems are continuously carried forward.
Additionally, the high release frequency may cause some app developers to struggle to keep up with the pace. As a result, certain apps might no longer function properly, or errors could occur when upgrading to the new version.
What if, instead of releasing three versions per year, only one or two was published? This would free up more resources to fix existing issues, and instead of offering just one year of support, it might be possible to extend it to two years or even longer. This would also increase the lifespan of the apps.
Just a few uneducated thoughts from a non-developer…
Those who want only one release per year should be aware that even if this were the case, it would not mean that once a release was done, 100% of development time would be spent on fixing bugs for the current release, and no one would be working on new features for an upcoming release. In all major software projects, whether they have fixed release cycles or not, and regardless of how often they release, both things are usually done in parallel these days, otherwise new features would never be released…
Take Debian, for example, which has a reputation for being super stable. When a stable version is released, the next version is already being worked on, and at the same time bug fixes and security fixes are being ported back into the current stable version.
Think of releases as snapshots, or a freeze, of a certain development state at a certain point in time, which is then preserved and maintained for a certain amount of time until it is replaced by the next snapshot.
Developing and maintaining software is a continuous process, regardless of release schedules, and an annual release cycle doesn’t necessarily mean fewer bugs. In fact, it could lead to more issues after a new version is released, since fewer users would be testing and reporting bugs throughout the year.
Additionally, the high release frequency may cause some app developers to struggle to keep up with the pace. As a result, certain apps might no longer function properly, or errors could occur when upgrading to the new version.
App developers are on a different schedule: deprecated APIs are announced 3 years ahead of time and carried (still supported) through 9 to 12 major releases before being formally removed.
As you can see in the past, they are not blindly pushing out versions, in some years there have been just 1 (2017) or 2 (2019, 2022) releases. How was the situation then?
I think they should know themselves, if you are a developer and you feel to rushed, there are other channels to communicate with them (developer chats, github, conferences, …).
Your issue are bugs that are not fixed. First of all, you never can fix all bugs. Some bugs are fixed quickly, others take more time.
So the question comes back which bugs are open too long, which ones are bothering the community the most?
In the past they had hackathons dedicated to hunt down bugs, first try to reproduce old ones, and then try to fix them.
I think, we need to address the real issue. And if there are too many bugs, perhaps these concerns areas where the code is not tested enough (new bugs slip in), bugs are just not fixed, …
In recent times, over 10,000 Issues are handled (closed out) annually across the Nextcloud repositories. In addition, numerous other matters are handled directly in Pull Requests without associated Issues.
Based on 2024 data… the server repository saw:
~165 Issues closed out per month
~358 code merges per month (excludes translation updates and minor automated dependency updates)
To look across the entire project, two organizations have to be looked at: nextcloud (which includes the previously mentioned server repository) and nextcloud-libraries… the data for 2024 at that level is:
~873 Issues closed out per month
~2233 code merges per month (excludes translation updates and minor automated dependency updates)
Of course new Issues and Pull Requests are being created constantly as well.
If you want to help:
Create a GitHub account then visit the repository for one of the components or apps you use somewhat regularly then:
upvote any open Issues you’re impacted by (this helps not only with prioritizing work around fixing the big itself, but also prioritizing the inbound triaging efforts themselves)
read open Issues and try to reproduce the reported matter and/or request additional information from the reporter
redirect non-bug reports (i.e. configuration/support matters) here to the forum and/or to the documentation
help identify duplicates and link them
identify areas of weakness in the documentation and create relevant Issues or PRs in the dedicated documentation repository
And, yeah, not all bugs are equal. All the Issues with only a single reporter (and no upvotes or maybe only one or two) are often too obscure to be important or turn out to be configuration matters, etc. Also sometimes they’re simply duplicates, but it takes a lot of time to read through problem descriptions and connect all the dots to existing Issues.
