I also asked my self many times why you run away with new major releases.
You are being well accepted and wide-spread! This means your users are more and more non-experts but serious in trusting you, they deserve very cautious ans flawless upgrade procedures.
Please, improve quality and don’t run for feature extensions.
NC is great. but not many can afford tricky update hick-ups
I literally wanted to ask something similar a couple of days ago, then was distracted and postponed it.
In particular, I think if versions are incremented that often, then there should be a separate API versioning, such that at least the API remains stable between releases.
It seems like a bad joke, that before most apps are modified to support v26, there’s already a beta of v27. At that pace, the vast majority of apps is always marked as “incompatible”, meaning one either has to run a way outdated version of Nextcloud, or one must enable incompatible apps, and then has a hard time tracking down why something doesn’t work, if just one of these causes issues, as it could be one of dozens.
Imagine, if you will, that M$ or Apple would release major versions of their operating systems every few months, and each time all apps released would be marked as incompatible, and would have to be re-enabled with special administrator privileges, under the risk that they can break things.
Nexcloud really is “operating system level” infrastructure, hosting apps.
As such it needs API stability, and sufficient insulation, that no matter what changes in the app, as long as the API isn’t changed in a non-backward-compatible way (which should be exceedingly rare), apps of vN should be expected to work with vN++
I suspect that to obtain a slower cadence and a more stable API, you may be required to look at the Next-cloud enterprise Nextcloud Enterprise for enterprises and organizations it does list on the comparison chart that you will receive “Enterprise QA” and the ability to influence the development roadmap.
I also suspect that the wider spread community version is basically the UAT stage of nextcloud development.
There are two major releases every year. Updates are delivered for the current and the last two older versions. So, app / API stability is guaranted till eol, at least one year after release date. If you stay one release back, you’ll stay safe. Got never problems with this update strategy.
It’s quite a few releases since any feature that was even of passing interest to me.
I would much prefer that there was an option to be on a “slow” channel that only got bugfixes and security patches until the underlying OS went out of long term support.
Not addressing the OP query directly but more some of the follow-up comments/posters…
I have a bunch of NC installations for testing and supporting and (light) development, but production stays one major release back (and occasionally two) depending on timing and maturity of the next latest release.
No one is forcing anyone to update (minor version bumps) let alone upgrade (major version bumps). The only formal recommendation is to run a currently supported release. This means one receiving bug fixes and security patches.
The NC devs maintain 2-3 parallel supported free release trains at any given point in time.
Up until a couple weeks ago - and assuming you’re not a paid enterprise customer with more leeway - that could have been v24 even for all of us freeloaders. Now it’s time to shift to v25 if you want to continue to be conservative in your production deployments. That’s fine - it’s been out awhile and received a lot of minor updates at this point. It’s a fairly known quantity.
I think people (users - admins are users too!) often suffer from an inability to just stick to deploying minor release updates until the next major release has quite a few proven point releases (i.e. time in the field, well understood issues, and a slowing of the cadence of its development).
I get it - it’s human nature.
The funny thing is that we all also collectively benefit from other people updating before we do and seeing what breaks and helping the devs get to the bottom of bugs.
My only suggestion to most normal users of NC is to be conservative in their production environment.
And if you must scratch an itch to upgrade rapidly, do whatever is necessary to create yourself a staging or testing environment. (Tip: If you’re using Docker that’s literally as easy as creating a second Compose file and changing a port number or IP address assignment for the test/staging environment. Highly recommended over doing blind - i.e. not personally tested and evaluated - upgrades or even minor updates).
Congratulations - you’re a real sys admin now. That’s what you volunteered for when you decided to not just use retail public cloud hosting/file/doc/app services.
Hi Daniel. It seems you answered to a question through email as though it had been directed at you personally. This was a forum post published publically. Maybe open this in your browser and you’ll see what I mean.
Let’s have a look in a different way: There are accumulating some changes over time that need to be brought online at some point but that will break some structure for the apps. To not have to wait for 2+ years, this rather quick moving major release cycle is installed.
This means for one that app maintainers need to keep a close eye on the updates and mark their apps as compatible. However, this also means that the changes between major versions are rather small in terms of API. It is not like a complete rewrite where you have to rewrite your app. This makes maintaining more continuous and less burst-like.
Sorry, that’s continuous delivery at it’s best. I never made an experience, that a (featured) app stopped working because of an upgraded API. Do you have an example? If you want to stay safe, stay one version behind. Even in a productive environment. Beside that, a test environment and a fast and reliable rollback strategy is always a good idea.
What you actually saying is, I want Enterprise LTS versions for free. I mean in theory you can have that. The code is open source, you just have to backport all the security fixes yourself
And btw, when it comes to the apps, the opposite can happen too, especially with apps that are typically used by home users. So it might be possible that some apps require a minimum PHP version or minimum NC version, and would not run on a two year old enterprise version, at least not in their latest version.
However, you can mitigate the problem by updating more conservatively. Within a few weeks most poular apps are usually ready for the latest NC release. Simply wait with major upgrades until the .1 or .2 release is out, or if you want to be extra safe stay one major version behind latest. If you’re doing it like that you should never get into the situation that an app is not yet ready, and if it is, the app has probably been abandoned…
The long support cycles take a lot of resources that are then not available for new developments and improvements. Making this a payable option, these companies provide some money for this additional work.
For myself, I don’t consider the release cycle to be a real problem. You can do a major upgrade twice a year what’s the issue? For most, this works without big issues (with some exceptions). I’m more worried about app development, that they keep up with the release cycle and all the changes.
To facilitate the upgrades, the process has been improved in the early versions of the Nextcloud fork. Things change, perhaps we get to a state, where the whole eco-system is more stable and more foreseeable so that we could consider more minor releases instead some of the major releases. But for that purpose, the developer conference is a good point to discuss these topics, since they exchange a bit on the coming features and ideas.
I am not a programmer but it seems like the discussion of API changes would likely be changes to the API that add new functionality (in which case the app ecosystem would not depend on this API feature) or occasionally changing a “big” thing to be done the “Right Way” when it wasn’t before. In either case it seems like it would be less common or less of a big deal for an app to need major changes from version to version unless it is adding new features. I could be wrong since I have not programmed any apps for Nextcloud but I am curious as to those who have actual experience with this how much of an issue it really is in reality rather than in theory.
I agree in theory if you changed every element of the API every version it would be a nightmare, but surely that is not happening.
I would imagine a large part of the challenge is simply staying on top of PHP upgrades.