# Nextcloud Quality and Release-Cycles

**URL:** <https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784>\
**Category:** 🏷️ General\
**Tags:** release\_shedule, off-topic\
**Created:** [January 23, 2024, 6:44pm UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784 "2024-01-23T18:44:50Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Dennis1993](https://help.nextcloud.com/user_avatar/help.nextcloud.com/dennis1993/32/21257_2.png) [@Dennis1993](https://help.nextcloud.com/u/Dennis1993)\
**Post date:** [January 23, 2024, 6:44pm UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/1 "2024-01-23T18:44:50Z")

</div>

hey,

I’m a big fan of NextCloud and always try to help everywhere.

I’m noticing more and more that there are fewer inquiries here. Threads remain unanswered, there are thousands of issues on Github and they aren’t getting fewer, and every 3-4 months there is a completely new release from NextCloud.

The many issues on Github and the many open, unanswered topics bother many people. We are all aware that everyone can help here and many do it voluntarily, just like myself.

Wouldn’t it make sense if we changed the release cycle and said that e.g. there is only a completely new version once a year (major) and otherwise only bug fix releases (28.0.1, 28.0.2, 28.0.3…)?  
This also means that instead of constantly adding new features over the year, it’s primarily about code quality and big fixing.

This would give us all more time to support apps for the current version (see Office Online, which is still not compatible with v28) and we could work through the issues together on Github. For users the upgrade process to a new major is easier because one time in a year and not 3-4 times per year.

It seems to me that everything is done too quickly here and as a result the quality has dropped recently.

What do you all mean?

And a small question: only real bugs should be posted on GitHub, right?  
Then we should check together whether we should strictly close all other requests with a reference to this community, since then it is a configuration error. Would that make sense?  
Then we have a better overview to monitor bugs and prio them. 🙂

Thanks!

---

<div class="post-metadata">

**Author:** ![devnull](https://help.nextcloud.com/user_avatar/help.nextcloud.com/devnull/32/27793_2.png) [@devnull](https://help.nextcloud.com/u/devnull)\
**Post date:** [January 24, 2024, 9:43am UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/2 "2024-01-24T09:43:47Z")

</div>

I agree with you that the release cycle is far too short. Many of the innovations between two release cycles are only of interest to a small number of users and many of them don’t receive these updates anyway, as outdated Nextcloud instances are then upgraded or abandoned over several releases anyway.

What speaks in favor of rapid innovation is the open source community. The majority of programmers program what is fun. Frank Karlitschek has already given good interviews about this. For programmers, the release cycle is perhaps even too long.

**Example** [MagentaCLOUD](https://cloud.telekom-dienste.de): It is still on Nextcloud 25.0.13. Where is the innovation there? It will be a lot of fun to carry out the updates until Nextcloud 28 or later. It would be better for Deutsche Telekom if the interim releases had never existed.

It would be interesting to know how often Microsoft has to update their cloud for Microsoft 365 to estimate the maintenance effort for Microsoft vs. Nextcloud. In the end, both cost money.

---

<div class="post-metadata">

**Author:** ![wwe](https://help.nextcloud.com/user_avatar/help.nextcloud.com/wwe/32/72963_2.png) [@wwe](https://help.nextcloud.com/u/wwe)\
**Post date:** [January 25, 2024, 9:36pm UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/3 "2024-01-25T21:36:39Z")

</div>

We had many many discussions regarding the release cycle here already… many users would prefer longer release cycles - and there are good arguments for this… other can’t wait until next release [Why is 23.0.1 so heavily delayed?](https://help.nextcloud.com/t/why-is-23-0-1-so-heavily-delayed/132133) and [Release of NC 24 delayed](https://help.nextcloud.com/t/release-of-nc-24-delayed/137919) there are very huge drawbacks for long support as well…

if you follow discussions here in the forum you will see lot of admins don’t touch the system for long time and feel the pain when they have to upgrade multiple NC major versions at once, PHP and maybe OS as well. This is a clear result of ignorance - people only care when they have to… and longer release cycles would result in even more ignorance - _why upgrade the system if it’s still “supported”?_ **…and** _I don’t care there are myriads security patches between my release and the current one_

… in the ideal world everybody would install minor upgrades fast and there would be low pressure from new features to create major upgrades… in real world there are two drivers for admins to upgrade - support and features… given the fact most of the features added to the application address businesses and don’t motivate many users to upgrade only the support argument remains… which must be short enough people upgrade often… additionally NC relies on PHP which has tight yearly release schedule as well - there no good way to build PHP-based software with long release cycles when the basement changes every year… we had this discussion shortly regarding end-of-life of #php74 [On the roadmap: deprecation of PHP 7.4](https://help.nextcloud.com/t/on-the-roadmap-deprecation-of-php-7-4/149848) lot of good argument pro and contra frequent releases are written and referenced there. as my verdict I appreciate fast major release cycles… **everybody** can afford a major upgrade once a year - and there is almost no effort to apply each minor upgrade to keep the system secure.

I absolutely agree Nextcloud must improve in terms of quality and stability. definitely there is room for improvement in managing Github issues… but the point is there is no “we”… the product is mainly driven by the company and the voice of community is not really loud. The company owns the the code repository, it decides which features get in/out and how fast… you can read lengthy and interesting discussion [Do we need a formal, democratic, non-profit Organization for organizing the Nextcloud community?](https://help.nextcloud.com/t/do-we-need-a-formal-democratic-non-profit-organization-for-organizing-the-nextcloud-community/115947) many reasons why things are how things are now mentioned there. My opinion is still the same - **one** healthy and strong community is better than many… this means we have to live with and accept the limits applied by the company…

---

<div class="post-metadata">

**Author:** ![tflidd](https://help.nextcloud.com/letter_avatar/tflidd/32/6_22734026db12803ebb3e059622ac3534.png) [@tflidd](https://help.nextcloud.com/u/tflidd)\
**Post date:** [January 26, 2024, 1:01pm UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/4 "2024-01-26T13:01:35Z")

</div>

> [@Dennis1993](#):
>
> And a small question: only real bugs should be posted on GitHub, right?  
> Then we should check together whether we should strictly close all other requests with a reference to this community, since then it is a configuration error. Would that make sense?  
> Then we have a better overview to monitor bugs and prio them.

Yes, bugs are usually in github, often feature requests as well. Unless it is really urgent, or there are really patches being worked on, it is not easy and possible to see the status.

> [@wwe](#):
>
> the voice of community is not really loud.

You have the thumbs up on the github issues to see what people care about. Some good features were implemented over time (easier way to decrypt data etc.) but it is not like for customers that you have a certain response time, except if it blows up something important, for special use cases, bugs can remain open for a long time.

---

<div class="post-metadata">

**Author:** ![JimmyKater](https://help.nextcloud.com/user_avatar/help.nextcloud.com/jimmykater/32/4850_2.png) [@JimmyKater](https://help.nextcloud.com/u/JimmyKater)\
**Post date:** [January 26, 2024, 3:23pm UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/5 "2024-01-26T15:23:20Z")

</div>

> [@wwe](#):
>
> **everybody** can afford a major upgrade once a year

'nuff said.

Why once a year? With mostly 3 new major versions every year you only need to update once a year to the then newest version (don’t skip any major versions, though) to avoid running [EOL](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule)-versions.

---

<div class="post-metadata">

**Author:** ![Bodenseematze](https://help.nextcloud.com/user_avatar/help.nextcloud.com/bodenseematze/32/74520_2.png) [@Bodenseematze](https://help.nextcloud.com/u/Bodenseematze)\
**Post date:** [January 29, 2024, 8:03am UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/6 "2024-01-29T08:03:05Z")

</div>

I totally agree with [Dennis1993](https://help.nextcloud.com/u/Dennis1993) - for me the big “releases” are way to often.  
Three main versions a year are too much! And to support a main version only for a year is not very user friendly!  
One main release (which may break some interfaces etc.) per year would be enough!  
And support should be given at least for two years!

It would be no problem to have more main releases if the quality would be better and an upgrade would work without (big) problems.  
But I always have to fear that one of my apps no longer work (or that an internal interface has been changed so that a maintainer of a third party app was not able or willing to rework it’s plugin to support multiple main releases per year) or that a functionality which I use is no longer supported or…

And I absolutely cannot understand the arguments about the PHP versions.  
8.0.0 was released 2020/11/26 and was supported until 2023/08/03 - nearly three year!  
8.1.0 was released 2021/11/25 and is still supported!

I use NC as picture and documents store as well as calendar and contacts server for a department in a non profit sports club.  
I configure and manage it in my spare time - as non paid volunteer work.  
To be on a stable version I never use the latest main version of NC - I use the version before it (currently v27).  
I normally try to be at the latest sub version of that version - but I always wait some days to install it to see if I have to expect problems with it or not…  
…and I still fear an update!

I’m nearly sure a lot of users use it the same way and would like to slow done the release cycle!  
But I’m also nearly sure that this discussion here is in vain and that nothing will change 🤔

---

<div class="post-metadata">

**Author:** ![andre\_x](https://help.nextcloud.com/letter_avatar/andre_x/32/6_22734026db12803ebb3e059622ac3534.png) [@andre\_x](https://help.nextcloud.com/u/andre_x)\
**Post date:** [January 29, 2024, 8:52am UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/7 "2024-01-29T08:52:58Z")

</div>

I’m a nobody, just a home user and I totally agree with @Dennis1993. 3 major release a year are waaaay too many. Are there other software that do that?

---

<div class="post-metadata">

**Author:** ![tflidd](https://help.nextcloud.com/letter_avatar/tflidd/32/6_22734026db12803ebb3e059622ac3534.png) [@tflidd](https://help.nextcloud.com/u/tflidd)\
**Post date:** [January 29, 2024, 12:39pm UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/8 "2024-01-29T12:39:20Z")

</div>

> [@andre\_x](#):
>
> Are there other software that do that?

Google chrome, 1 per month. And they have extension as well.

---

<div class="post-metadata">

**Author:** ![bb77](https://help.nextcloud.com/letter_avatar/bb77/32/6_22734026db12803ebb3e059622ac3534.png) [@bb77](https://help.nextcloud.com/u/bb77)\
**Post date:** [January 29, 2024, 1:10pm UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/9 "2024-01-29T13:10:38Z")

</div>

Just to put things a bit in perspective, I would like to comment on some of the points that you have made:

> [@Bodenseematze](#):
>
> Three main versions a year are too much! And to support a main version only for a year is not very user friendly!

Actually you only have to update once a year. Sure, if you do that you might then have to do two updates at once because you can’t skip versions, but I think that’s still pretty reasonable for a product like Nextcloud: [https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule)

## Currently maintained versions

| Version code | Version name | Release date | [End of life](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule) | Current version | Next version |
| --- | --- | --- | --- | --- | --- |
| **28** | Hub 7 | 2023-12-12 | 2024-12 | **28.0.1** (2023-12-21) | **28.0.2** (2024-02-01) |
| **27** | Hub 6 | 2023-06-13 | 2024-06 | **27.1.5** (2023-12-14) | **27.1.6** (2024-01-25) |
| **26** | Hub 4 | 2023-03-21 | 2024-03 | **26.0.10** (2023-12-14) | **26.0.11** (2024-01-25) |

> [@Bodenseematze](#):
>
> And support should be given at least for two years!

Well, more is of course always better, but again I think one year is perfectly reasonable for a product like Nextcloud that you can use completely for free.

> [@Bodenseematze](#):
>
> It would be no problem to have more main releases if the quality would be better and an upgrade would work without (big) problems.  
> But I always have to fear that one of my apps no longer work (or that an internal interface has been changed so that a maintainer of a third party app was not able or willing to rework it’s plugin to support multiple main releases per year) or that a functionality which I use is no longer supported or…

Well, this can indeed be an issue, but then again this is the case with any software relying on third party plug-ins. However, usually you only have to wait a few days after a new version of Nextcloud got released. The majority of the apps is actually pretty well maintained.

Of course, there are also some apps that are not well maintained, or an app may get abandoned altogether. The reason for this can be as simple as the developer not having the time (or motivation) to continue working on it. You should always bear in mind that many third-party apps are developed by volunteers in their spare time.

I cannot comment on whether it is particularly difficult to develop for Nextcloud, because I’m not a developer, but I do know that not every major release of Nextcloud requires fundamental changes. Often all the devs have to do is bumping the version number. But yes, Nextcloud is a very agile project, so developing an app and then using it unchanged for years will hardly ever be possible, but where else is that still possible nowadays?

> [@Bodenseematze](#):
>
> 8.1.0 was released 2021/11/25 and is still supported!

Not sure what the issue is then, Nextcloud 28 still officially supports PHP 8.1: [System requirements — Nextcloud latest Administration Manual latest documentation](https://docs.nextcloud.com/server/28/admin_manual/installation/system_requirements.html)

> [@Bodenseematze](#):
>
> I’m nearly sure a lot of users use it the same way and would like to slow done the release cycle!  
> But I’m also nearly sure that this discussion here is in vain and that nothing will change 🤔

No, probably not, but you can avoid most of the issues you described, if you follow one simple rule:

Wait at least for the first, or better the second, point release before upgrading your production instance to a new major release.

Or, if you don’t care about the latest and greatest, you can always use the second latest version, and upgrade to 28 when 29 comes out, and then to 29 when 30 comes out etc. That way you would still have to upgrade three times a year, but the version you upgrade to will be much more mature and all the apps will be compatible by the time you upgrade your instance.

---

<div class="post-metadata">

**Author:** ![Bodenseematze](https://help.nextcloud.com/user_avatar/help.nextcloud.com/bodenseematze/32/74520_2.png) [@Bodenseematze](https://help.nextcloud.com/u/Bodenseematze)\
**Post date:** [February 6, 2024, 4:41pm UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/10 "2024-02-06T16:41:45Z")

</div>

But I _have_ to update to each version - as skipping (update from e.g. v25 directly to v27) is not supported.  
In theory each upgrade works flawless - but in (my) reality a lot of upgrades failed or caused hard to solve problems.  
So for me it’s a spoilage to say “you only have to update once a year”. Yes, you only _have_ to do it once a year - but then you have to do it for the missing versions, too!

I assume that the plugin / third party authors try to follow the NC releases - but most of the time they’re working on their things in their spare time.  
And supporting several main versions a year can be frustrating - especially if interfaces changes a lot.  
If the frustrating level is to high (or the interface changes are to big to “re-release the wheel”) they’ll abandon it.

My note about the supported PHP version was a comment against @wwe’s post that NC has to follow the PHP release schedule - it should show that PHP much longer supports versions than NC does!  
BTW, what would happen if PHP would do three main versions a year and stop support for older versions?  
I’m nearly sure that a big outcry would follow - of course also from NC developers!

The last paragraphs of your post show exactly what I do - I currently use v27 and’ll keep it alive until v29 has some release (at least 4 or 5) - then I’ll upgrade to v28  
And I always wait a few days and have a look at the forum if a specific version causes known problems before I update to it - my problems in history when upgrading and updating shows that that is a good idea!

Again: I’m nearly sure that most of the NC users would be happy if not so much main releases a year would occur - but it seems the users voice will not be heard ☹

---

<div class="post-metadata">

**Author:** ![wwe](https://help.nextcloud.com/user_avatar/help.nextcloud.com/wwe/32/72963_2.png) [@wwe](https://help.nextcloud.com/u/wwe)\
**Post date:** [February 6, 2024, 9:32pm UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/11 "2024-02-06T21:32:48Z")

</div>

> [@Bodenseematze](#):
>
> I’m nearly sure that most of the NC users would be happy if not so much main releases a year would occur - but it seems the users voice will not be heard

I don’t think the release cycle is out of blue there.. likely there is some pressure from user asking for new features which require major releases and API changes. maybe this users are commercial and institutional so we don’t hear the voice _here_. but there is definitely a reason for the frequency. and again even with this update cycle we see people asking for support for 2-3y old versions.. now it’s immediately clear the version is outdated.. if there would be kind of LTS with dozens minor security updates - much more admins would skip this updates running insecure installations. this is the main reason I prefer fast major lifecycle. if you can’t leave with it - Nextcloud is OSS - fork and maintain your own long supported version if you can.

---

<div class="post-metadata">

**Author:** ![JimmyKater](https://help.nextcloud.com/user_avatar/help.nextcloud.com/jimmykater/32/4850_2.png) [@JimmyKater](https://help.nextcloud.com/u/JimmyKater)\
**Post date:** [February 7, 2024, 12:52pm UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/12 "2024-02-07T12:52:48Z")

</div>

> [@Bodenseematze](#):
>
> I’m nearly sure that most of the NC users would be happy if not so much main releases a year would occur

err how do you know? do you have a crystalball telling you this?

By all respect: just because there’s a small number of users critizing the release-cycle every now and then (estimated around 30) very loudly and again and again what does that mean compared to the hundreds of thousands private installations whose owners apparently doesn’t complain?

all in all and always again: you only need to update once a year to stay on a supported version. it’s not only a matter of new features but also a big matter of security.  
If you, as an admin and owner of your instance, decide to stay longer with an unsupported version, that’s up to you and your own responsibily. you can even update at a later time, after [EOL](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule) was reached. It’s just not recommended.

so if you’d stay with nextcloud please expect between 2 and 4 new major versions every year. and be sure that nobody wants to force major versions just for fun. There’s always a reason for it. Always. For the security of your own data!

---

<div class="post-metadata">

**Author:** ![bb77](https://help.nextcloud.com/letter_avatar/bb77/32/6_22734026db12803ebb3e059622ac3534.png) [@bb77](https://help.nextcloud.com/u/bb77)\
**Post date:** [February 7, 2024, 2:02pm UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/13 "2024-02-07T14:02:52Z")

</div>

> [@Bodenseematze](#):
>
> In theory each upgrade works flawless - but in (my) reality a lot of upgrades failed or caused hard to solve problems.

I haven’t had any issues with the actual update process for a long time. If you repeatedly experience issues when updating your instance, feel free to post in the support section the next time it happens.

> [@Bodenseematze](#):
>
> But I always have to fear that one of my apps no longer work (or that an internal interface has been changed so that a maintainer of a third party app was not able or willing to rework it’s plugin to support multiple main releases per year)

> [@Bodenseematze](#):
>
> I use NC as picture and documents store as well as calendar and contacts server for a department in a non profit sports club.

So what are the third party apps you are using then? Files, Photos, Calendar, Contacts are all official apps.

> [@Bodenseematze](#):
>
> To be on a stable version I never use the latest main version of NC - I use the version before it (currently v27).

Ok, and are you experiencing any particular issues with this version? If not, you can use it until June 2024. By then, all serious bugs and regressions in Nextcloud 28 will likely be fixed, and it should work at least as good as NC27, most likely even better.

Apart from that, I can only add the following…

Maintaining your own Nextcloud server requires a certain amount of extra effort compared to what we are used to with mobile apps or desktop software nowdays. But I guess that’s the price we have to pay for a software like Nextcloud to be completely free (free as in freedom and free as in beer), which seems fair to me.

---

<div class="post-metadata">

**Author:** ![tflidd](https://help.nextcloud.com/letter_avatar/tflidd/32/6_22734026db12803ebb3e059622ac3534.png) [@tflidd](https://help.nextcloud.com/u/tflidd)\
**Post date:** [February 7, 2024, 4:39pm UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/14 "2024-02-07T16:39:55Z")

</div>

I could live with less upgrades, I don’t need that many. However, if they run without problems (like they currently do for me), it’s not a real issue either.

They decided on such a release cycle in the beginning after the fork from owncloud, and said it was suited for the time then. Now, there are already the Nextcloud Hub versions, that increase less quickly, and perhaps they could become major upgrades you can do directly? But that is just me thinking loud.

For us it is easy to ask for changes, to implement everything and communicate especially when it is different from before, that requires some planning and you shouldn’t change it too often. And so, I personally would change it only, if I’m relatively sure about it, and the arguments are valid.  
For paying customers, they offer longer support cycles, from that they should be aware of the impact.

---

<div class="post-metadata">

**Author:** ![jtr](https://help.nextcloud.com/letter_avatar/jtr/32/6_22734026db12803ebb3e059622ac3534.png) [@jtr](https://help.nextcloud.com/u/jtr)\
**Post date:** [February 8, 2024, 6:21pm UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/15 "2024-02-08T18:21:23Z")

</div>

I’m sort of confused by the release cycle aspects of this thread because there’s a difference between the release cycle of new _major_ releases and releases of minor/patch releases.

The only updates anyone has to do to maintain a stable environment are to:

- pick one of the _three_ supported major release trees to deploy (essentially oldest is most mature/field tested; middle is fairly mature, and latest is - not surprisingly - least mature). All three receive critical security and bug fixes.
- install minor/patch updates as they come out (which are generally low risk since they only can contain critical bug fixes unless we screw something up) [roughly once a month]
- once a year bump up to one of the still supported major releases (which means you can still be running v26 and be up-to-date with all security fixes and critical bug fixes as I write this and only need to upgrade to the now fairly mature v27 when v26 reaches [end of life](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule) after it’s one year run - which happens to be next month)

The project maintains support for three major releases simultaneously - which takes extra effort and time - already.

It’s basically no different than deciding which version Fedora, Debian, or Ubuntu to run.

It is true there is no _supported for 3-5 years_ major release. (Though you can pay somebody to support you for that long). That’s life. But there always is a really mature release, a fairly mature release, and a less mature release. Pick your poison.

We can’t protect users from themselves - if you just can’t avoid clicking the button (or whatever) to upgrade to the latest bleeding edge _major_ release… Well that’s kind of on you.

We’re doing all the work to keep v26 supported so that those with an interest in running a more battle tested major release can do so.

Soon that’ll be v27.

I keep hearing this sort of thing come up. Is there a messaging issue? Is the update notice in the web interface unclear? What could be we doing better to communicate this?

> [@Bodenseematze](#):
>
> I configure and manage it in my spare time - as non paid volunteer work.  
> To be on a stable version I never use the latest main version of NC - I use the version before it (currently v27).  
> I normally try to be at the latest sub version of that version - but I always wait some days to install it to see if I have to expect problems with it or not…  
> …and I still fear an update!
> 
> I’m nearly sure a lot of users use it the same way and would like to slow done the release cycle!

I mean… That sounds like it’s working how it’s supposed to. What does it matter if v28 is released? You can use v27 until it reaches [end of life](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule). We put out critical fixes for it. You’re golden.

Heck, I run v26 in my production environment because I’m insanely conservative about my data. Going to v27 this month. 🙂

---

<div class="post-metadata">

**Author:** ![bb77](https://help.nextcloud.com/letter_avatar/bb77/32/6_22734026db12803ebb3e059622ac3534.png) [@bb77](https://help.nextcloud.com/u/bb77)\
**Post date:** [February 8, 2024, 6:46pm UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/16 "2024-02-08T18:46:21Z")

</div>

I understand it like this.

He wants to be able to press a button, and two minutes later the update is done and everything runs smoothly without any major changes, except maybe a few new cool features. Just like a cell phone app.

Also, he often seems to have issues with the update process itself, which could be caused by a cheap web hosting and/or a sub-optimal server configuration.

And then there’s the fear that the user interface changes or an important app stops working.

At the end of the day, I can only say that a managed Nextcloud would probably be the best solution in this case.

---

<div class="post-metadata">

**Author:** ![jtr](https://help.nextcloud.com/letter_avatar/jtr/32/6_22734026db12803ebb3e059622ac3534.png) [@jtr](https://help.nextcloud.com/u/jtr)\
**Post date:** [February 8, 2024, 7:07pm UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/17 "2024-02-08T19:07:16Z")

</div>

> [@Dennis1993](#):
>
> there are thousands of issues on Github and they aren’t getting fewer,  
> […]  
> The many issues on Github and the many open, unanswered topics bother many people

Re: GitHub

Not getting fewer isn’t the same thing as not getting handled (I’ll explain that statement in a moment). And the majority of open issues (at least in the main `server` repository) are enhancement ideas, not bug reports.

Let’s look at the `server` repository (understandably one of the more central ones that is relevant to every Nextcloud user)[1]:

- Today there are 2,218 open issues. Of these:
  - 1,304 are enhancement ideas. We want this number to grow. This is a good thing. It’s a pool of ideas for developers/contributors/users to draw from to make Nextcloud Server better
  - ~200 of these are technical debt. These ultimately are essentially enhancements one way or another
  - ~900 are bug reports

In the past 30 days (looking at the Insights/Pulse board [here](https://github.com/nextcloud/server/pulse/monthly):

- 240 issues were closed out while
- 147 new ones were created
- If you want to understand the Issues in other ways, you can look at the labels used and quantity of issues for each label [here](https://github.com/nextcloud/server/labels?sort=count-desc) and mix and match them however you want

Btw: if anyone reading this feels qualified to assist on an open Issue they run across - such as to help determine whether a given open Issue is a a real bug or merely a config matter that needs to get redirected here to the forum - feel free to jump in and do so! A lot of the time the developers and issue triagers spend is merely identifying duplicate reports, redirecting people here or to documentation, etc. When developers have to do this, it consumes time otherwise spent on fixing bugs, addressing technical debt, and implementing desirable enhancements or new features.

[1] Btw, there are over 300 independent repositories in the project!

---

<div class="post-metadata">

**Author:** ![JimmyKater](https://help.nextcloud.com/user_avatar/help.nextcloud.com/jimmykater/32/4850_2.png) [@JimmyKater](https://help.nextcloud.com/u/JimmyKater)\
**Post date:** [February 10, 2024, 2:11pm UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/18 "2024-02-10T14:11:36Z")

</div>

> [@jtr](#):
>
> Is there a messaging issue?

I don’t think so at all. I’d say it’s more or less a motion in waves. Every now and then someone is fed up be the fact that there are roundabout 3 major versions during one year and that they feel they need to upgrade every 3-4 months.  
Well we all know that this feeling is wrong. Neither do you need to be early adoptor being on the last major version every time nor do you need to update more than once a year (ok then you’d need to do all the upgrading to the newest major version at once - and you’ll be done for another year).

This has been discussed on the forum several times before. I really can’t count it anymore. And it’s always circling around the very same arguments… and it’s rarely more than like 10 peeps complaining.

So all in all I’d say: business as usual. Even about that point. nothing to get yourself grey hair about.

---

<div class="post-metadata">

**Author:** ![Dennis1993](https://help.nextcloud.com/user_avatar/help.nextcloud.com/dennis1993/32/21257_2.png) [@Dennis1993](https://help.nextcloud.com/u/Dennis1993)\
**Post date:** [February 10, 2024, 4:11pm UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/19 "2024-02-10T16:11:37Z")

</div>

We’re talking a bit off topic here. My point was that the quality decreases due to the number of updates. It seems to me as if the developers themselves can no longer keep up. Bugs after bugs in every new version. And that’s are no small bugs (move files eg in v28).

The update for users remains to be seen. This can be handled.

---

<div class="post-metadata">

**Author:** ![tflidd](https://help.nextcloud.com/letter_avatar/tflidd/32/6_22734026db12803ebb3e059622ac3534.png) [@tflidd](https://help.nextcloud.com/u/tflidd)\
**Post date:** [February 11, 2024, 1:00pm UTC](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784/20 "2024-02-11T13:00:01Z")

</div>

> [@Dennis1993](#):
>
> My point was that the quality decreases due to the number of updates.

If I understand you correctly, it seems like recently Nextcloud increased the number of releases drastically (while it stayed the same), and because of that the quality went down.  
Since when? Just NC28, or from NC2x? Or just over the last two years?

I know it is hard to measure, even github issues and stuff like that, it depends a lot if you keep a lot of small issues, how you manage them (close not reproducible once, go often through issues to find and close duplicates), …

For NC28, quite a few things were removed (not just deprecated):  
[https://docs.nextcloud.com/server/latest/developer\_manual/app\_publishing\_maintenance/app\_upgrade\_guide/upgrade\_to\_28.html](https://docs.nextcloud.com/server/latest/developer_manual/app_publishing_maintenance/app_upgrade_guide/upgrade_to_28.html)  
and more compared to the versions before:  
[https://docs.nextcloud.com/server/latest/developer\_manual/app\_publishing\_maintenance/app\_upgrade\_guide/upgrade\_to\_27.html](https://docs.nextcloud.com/server/latest/developer_manual/app_publishing_maintenance/app_upgrade_guide/upgrade_to_27.html)  
[https://docs.nextcloud.com/server/latest/developer\_manual/app\_publishing\_maintenance/app\_upgrade\_guide/upgrade\_to\_26.html](https://docs.nextcloud.com/server/latest/developer_manual/app_publishing_maintenance/app_upgrade_guide/upgrade_to_26.html)  
[https://docs.nextcloud.com/server/latest/developer\_manual/app\_publishing\_maintenance/app\_upgrade\_guide/upgrade\_to\_25.html](https://docs.nextcloud.com/server/latest/developer_manual/app_publishing_maintenance/app_upgrade_guide/upgrade_to_25.html)

[Next page](https://help.nextcloud.com/t/nextcloud-quality-and-release-cycles/179784.md?page=2)
