Why is the major release incremented every 4 months? Is the API really shifting (breaking backwards compatibility) that often? The pace seems a bit fast for app developers to be able to keep up.
Iām assuming Nextcloud development uses semantic versioning. Is that true? If so Iām also curious why releases seem to be either major or patch releases, never (or rarely) minor.
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.
That is not the way upgrades work. The only workable solution is to not upgrade your production server unless you have tested that upgrade on a test instance. Or keep a backup you can rollback to.
My suggestion to Nextcloud would be to rename stable to ālatestā, but it is okay.
Either way, the way to maintain stability is to not constantly upgrade if you rely on the instance.
There is no way to force community developers to keep up with their app releases, so that is what it is.
Imagine a giant, free all-you-can-eat-buffet, which includes a community potluck. The only way to manage it is to practice some self control.
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.
Yes there are frequent API changes because of new added functions.
My problem is not this frequency of any major versions, but the ālackā of support (too short) of these versions.
Nextcloud should have a LTS release (outside of Enterprise Premiumā¦) maintained for 2 years. The lack of LTS (again, outside Enterprise subscriptions) is really bad
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.
