I feel the same, too many major updates, but few breaking improvements
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 
If they add that then there is no reason to buy enterprise âŚ
And you can stay on a major version for some time if you like.
This discussion come up a couple of times per year.
And everytime all these arguments pops up.
2 Likes
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âŚ
4 Likes
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.
3 Likes
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.
No, only saing that a good LTS policy is also part of good software. I would prefer paying for fontionalities rather than only old good software.
Thatâs called the enterprise channel
A home user license that provides access to LTS versions would certainly something they could offer. However, for reasons I donât know, they decided against it.
On the other hand, I donât think the situation is as bad as you and others make it out to be. As I said, with a more conservative update strategy you can actually get along pretty well. Of course, just clicking on an update button every two years and not worrying about anything else is not possible with Nextcloud (as with hardly any user facing software nowadays), and probably never will be.
Btw, if you only using the âFeaturedâ apps, and if you are not an app developer, you will have little to no issues with API changes anyways, because the core apps are usually ready when a new version major version of NC is released. Of course you still have to to do one or two major upgrades a year, but you wonât likely run into any major issues.
Yes they offer LTS, and even for free. Bu they also have commercial offerings of their software with additional features like e.g. cluster and HA functionality: Production-Grade Open Source Database: MariaDB Enterprise | MariaDB
I have discussions on just this for small business. I have several that really need some kind of small business license.
Yeah, there seems to be a gap for SMBs with less than a 100 users, however âŹ36/user/year seems reasonable to me. Nextcloud Enterprise pricing
On the other hand, you still need to maintain your instance, even with an Enterprise subscription, and therefore you still have to pay someone to to it. Or you can of course maintain it yourself, and pay with your time.
So either way, as a small company, there must be a large portion of idealism involved in order to justify hosting your main office platform yourself, because, if you want to do it right, it will probably always be more expensive (either in time or in money, most likely both) compared to something like M365 or Google Workspace.
1 Like
Let me be clear: iâm not talking about a LTS with normal backports, but, at least, with Security backports. For example, the v24 is now EOL. It passed from Active to EOL.
PHP has 3 phases : Active, Security, EOL.
This could be a good approach.
https://www.php.net/supported-versions.php
Not sure what you mean or where NC is fundamentally different to PHP, except for the fact that PHPs release cycles are longer. However, it doesnât really matter, because Iâm pretty sure, they wonât change anything, at least not anytime soon. And even if they should change their minds, and start selling subscriptions to end users or small businesses, they would most likely continue with their existing release cycles for the Community and Enterprise editionsâŚ
So Iâm afraid if you want to to see fundamental changes regarding their development process and release strategy, at least in the foreseeable future, youâll have to fork Nextcloud. Personally, I would certainly check out Bloocloud LTS once it is released, not sure if I would use it on my main server, though.
For such topic, it might be worth discussing this during the Nextcloud conferences, where community member are welcome as well and you can exchange with core developers and third-party app-developers and others. Not everybody can go there, but perhaps we can gather and vote for a few questions that we can ask and report back to the community.
In the early days, they chose the current model to be able to quickly improve the software. Perhaps this is or will be different, and it might be worth investing resources for that. Unfortunately, they are a company as well, and if this more flexible release support were a major source for income, it would be less likely.
I donât have an issue with the release cycle. Itâs about tying API changes to the releases. Again, think âweb operating systemâ, not âmonolithic appâ.
Take M$ Windows or macOS or even Linux: no matter how often I update any of these, my apps keep working. Why? Because despite all internal improvements and bug fixes, the API remains stable.
Except for low level apps, like real-time audio, things âjust workâ
So, what Iâm advocating moving to, now that Nextcloud clearly has matured to a significant degree, is keeping app and API versions separate.
API versions should be major.minor, where minor versions only ADD features without breaking any of the existing functionality. e.g. every app designed for API M.m is able to run on any version of Nextcloud with API version M.(m+x) (x being a positive natural number, of course )
Whenever an API version breaks backwards compatibility, thatâs when a new major number should be introduced.
That should not need to be the case more often than every 3-5 years, one should think,
Consequently, apps in the store could be designated a API version which they require, like e.g. 5.2 meaning they will not run with any API version lower than that, but will run with any API version 5.x (x >= 2) and will need to be requalified for API version 6.x
As a result, users, for the entire duration of the API 5 upgrade cycle, donât have to worry about that app anymore. But that doesnât mean that Nextcloud needs to be static in that time. API additions are possible at any time, and so are other bug fixes and feature upgrades. Meaning, if API version 5 should hold, NC could go from 26 to 37 while API goes from 5.0 to 5.9 and no apps designed for the 5.0 base would be unaffected by any of the changes.
3 Likes
Iâm not doing external app development and Iâm only a minor recent (outside) contributor to the core and various peripheral bits, but my take is that the major version number of NC is the API version.
In effect app releases in the app store are already tied to a particular API, which is exactly why there are multiple releases for any given listed at a given point in time. How this is managed at an app level varies - some apps manage to maintain the same version across NC versions while others have different major versions or release variations (e.g. contrast Deckâs releases versus Notesâ releases). I imagine this is a byproduct of a mixture of what NC API dependencies a given app has and individual choices made by app developers to maintain compatibility. Also, where the app version isnât compatible with multiple NC versions, itâs the app developers prerogative whether to backport functionality to builds for older NC versions or not (where itâs an option I mean).
If you havenât already, you may want to monitor the API/notables docs collected for each major release that is targeted at internal core+app developers as well as external app developers.
For example, here is the v26 set:
For apps versioning and release management, there is the NC suggested approach (particularly the Shipped Apps - Versioning section) which seems relevant to mention here as well:
In effect app releases in the app store are already tied to a particular API
Which are always tied to a Nextcloud server release, which is what is being discussed.
In my opinion what is being suggested is very reasonable: to untie the API version from the Nextcloud feature releases. This would alleviate the pressure for app developers to need to test their apps every few months. While not changing the maintenance schedule for the Nextcloud server.
Speaking as an app developer, I know I should be testing my app against Nextcloud 27 beta already, but I lack the motivation to do so. Partially because I feel like I just spent this effort for Nextcloud 26 not even 2 months ago.
3 Likes
Makes total sense. Honestly, this is itâs own discussion topic. Nextcloud 27 is set to be released in the next two weeks⌠perhaps there could be a way to manage app release compatibility untied from the API. Great idea!
1 Like
Yes but no. Nextcloud server doesnât always have removed/breaking APIs. The major releases are done by schedule, not by type of change. Deprecated APIs are also not removed in the next major but three major releases in the future at the earliest.
So for app devs it is relatively easy to upgrade.
5 Likes
Enterprise grade is simply not available for home users with a small number of users. There is no choice.